CIP Common Specification 


Volume 1 
Release 1.0 
June 5, 2001 


ControlNet International 
and 


Open DeviceNet Vendor Association 


This page is intentionally left blank 


Open DeviceNet Vendor Assoc. & ControlNet International 


EtherNet/IP Specification 


Release 1.0 


EtherNet/IP Specification 


Chapter 1 
Chapter 2 
Chapter 3 
Chapter 4 
Chapter 5 
Chapter 6 
Chapter 7 
Chapter 8 
Chapter 9 
Chapter 10 
Appendix A 
Appendix B 
Appendix C 
Appendix D 


Release 1.0 


CIP Common Specification 


Volume 1 


Table of Contents 


- Introduction to the Control and Information Protocol 
- Messaging Protocol 

- Communications Objects 

- How to Read Specifications in the Object Library 
- Object Library 

- Device Profiles 

- Electronic Data Sheets 

- Physical Layer 

- Indicators and Middle Layers 

- Bridging and Routing 

- Explicit Messaging Services 

- Status Codes 

- Data Management 

- Engineering Units 


Open DeviceNet Vendor Assoc. & ControlNet International 


ill 


This page is intentionally left blank 


Open DeviceNet Vendor Assoc. & ControlNet International 


EtherNet/IP Specification 


Release 1.0 


Volume 1: CIP Common Specification 


Chapter 1: Introduction to CIP 


Chapter 1: Introduction to CIP Volume 1: CIP Common Specification 


This page is intentionally left blank 


1-2 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 1: Introduction to CIP 


1-1 INTRODUCTION 


The Control and Information Protocol (CIP) is a peer to peer object oriented protocol that 
provides connections between industrial devices (sensors, actuators) and higher-level devices 
(controllers). CIP is physical media and data link layer independent. See Figure 1-1.1. 


Figure 1-1.1. Example CIP Communication Link 
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CIP has two primary purposes: 


e Transport of control-oriented data associated with I/O devices 


e Transport of other information which is related to the system being controlled, such 
as configuration parameters and diagnostics. 
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OBJECT MODELING 
CIP makes use of abstract object modeling to describe: 


e The suite of communication services available 
e ©The externally visible behavior of a CIP node 


e Acommon means by which information within CIP products is accessed and 
exchanged 


A CIP node is modeled as a collection of Objects. An Object provides an abstract 
representation of a particular component within a product. The realization of this abstract 
object model within a product is implementation dependent. In other words, a product 
internally maps this object model in a fashion specific to its implementation. 


A Class is a set of Objects that all represent the same kind of system component. An Object 
Instance is the actual representation of a particular Object within a Class. Each /nstance of a 
Class has the same set of attributes, but has its own particular set of attribute values. As Figure 
1-2.1. illustrates, multiple Object Instances within a particular Class can reside in a DeviceNet 
node. 


Figure 1-2.1. A Class of Objects 
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An Object Instance and/or an Object Class has Attributes, provides Services, and implements a 
Behavior. 


Attributes are characteristics of an Object and/or an Object Class. Typically, Attributes provide 
status information or govern the operation of an Object. Services are invoked to trigger the 
Object/Class to perform a task. The Behavior of an Object indicates how it responds to 
particular events. For example; a person can be abstractly viewed as an Instance within the 
Class Human. Generally speaking, all humans have the same set of attributes: age, gender, etc. 
Yet, because the values of each attribute vary, each of us looks/behaves in a distinct fashion. 
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Clas Atibate Values 


Human Mary Female 
31 
Jerry Male 
50 


The following Object Modeling related terms are used when describing DeviceNet services and 
protocol. 


Object — An abstract representation of a particular component within a product. 

Class — A set of objects that all represent the same kind of system component. A class is 
a generalization of an object. All objects in a class are identical in form and behavior, 
but may contain different attribute values. 

Instance — A specific and real (physical) occurrence of an object. For example: New 
Zealand is an instance of the object class Country. The terms Object, Instance, and 
Object Instance all refer to a specific Instance. 

Attribute — A description of an externally visible characteristic or feature of an object. 
Typically, attributes provide status information or govern the operation of an Object. 
For example: the ASCII name of an object; and the repetition rate of a cyclic object. 
Instantiate - To create an instance of an object with all instance attributes initialized to 
zero unless default values are specified in the object definition. 

Behavior — A specification of how an object acts. Actions result from different events 
the object detects, such as receiving service requests, detecting internal faults or 
elapsing timers. 

Service — A function supported by an object and/or object class. CIP defines a set of 
common services and provides for the definition of Object Class and/or Vendor Specific 
services. CIP common services are those whose parameters and required behaviors are 
defined in Appendix A. 

Communication Objects - A reference to the Object Classes that manage and provide 
the run-time exchange of implicit (I/O) and explicit messages. 

Application Objects - A reference to multiple Object Classes that implement 
product-specific features. 
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1-2.1 Object Addressing 


The information in this section provides a common basis for logically addressing separate 
physical components across CIP. The following list describes the information that is used to 
address an Object from a CIP network: 


e Media Access Control Identifier (MAC ID) - An integer identification value assigned 


to each node on the CIP network. This value distinguishes a node among all other 
nodes on the same link. 


MAC ID #1 MAC ID #2 


DeviceNet Link 
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Class Identifier (Class ID) - An integer identification value assigned to each Object 
Class accessible from the network. 
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e Instance Identifier (Instance ID) - An integer identification value assigned to an 
Object Instance that identifies it among all /nstances of the same Class. This integer is 
unique within the MAC ID: Class in which it resides. 


MAC ID #1 MAC ID #2 
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It is also possible to address the Class itself versus a specific Object Instance within the Class. 
This is accomplished by utilizing the Instance ID value zero (0). CIP reserves the Instance 
ID value zero (0) to indicate a reference to the Class versus a specific Instance within the 
Class. 
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e 6Attribute Identifier (Attribute ID) - An integer identification value assigned to a 
Class and/or Instance Attribute. 
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e Service Code - An integer identification value which denotes a particular Object 
Instance and/or Object Class function. 
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1-2.2 Address Ranges 


This section presents CIP defined ranges for the Object Addressing information presented in 
the previous section. The following terms are used when defining the ranges: 


e Open - A range of values whose meaning is defined by ODVA/CI and are common 
to all CIP participants. 

e Vendor Specific - A range of values specific to the vendor of a device. These are 
used by vendors to extend their devices beyond the available Open options. A 
vendor internally manages the use of values within this range. 

e Object Class Specific - A range of values whose meaning is defined by an Object 
Class. This range applies to Service Code definitions. 


Table 1-2.2. defines the ranges applicable to Class ID values. 


Table 1-2.2. Class ID Ranges 


FOhex - 2FFhex CIP Common 
300nex - 4FFhex | Vendor Specific 
500hex - FFFFhex | Reserved by ODVA/CI for future use 


Table 1-2.3. defines the ranges applicable to Service Code values. 


Table 1-2.3. Service Code Ranges 


Services. These are defined in Appendix ?. 


64hex - 7Fhex Reserved by ODVA/CI for future use 
80nex - FFhex Invalid/Not used 


Table 1-2.4. defines the ranges applicable to Attribute ID values. 


Table 1-2.4 Attribute ID Ranges 


00 - 63hex CIP Common 


64nex - C7™hex Vendor Specific 
C8hex - FFhex Reserved by ODVA/CI for future use 
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NETWORK OVERVIEW 


CIP defines a connection-based scheme to facilitate all application communications. A CIP 
connection provides a communication path between multiple end-points. The end-points of a 
connection are applications that need to share data. Transmissions associated with a particular 
connection are assigned an identification value when a connection is established. This 
identification value is called the Connection ID (CID). 


Connection Objects model the communication characteristics of a particular 
Application-to-Application(s) relationship. The term end-point refers to one of the 
communicating entities involved in a connection. 


CIP’s connection-based scheme defines a dynamic means by which the following two types of 
connections can be established: 


e 1/0 Connections - Provide dedicated, special-purpose communication paths between a 
producing application and one or more consuming applications. Application-specific 
I/O data moves through these ports and is often referred to implicit messaging. 

e Explicit Messaging Connections - Provide generic, multi-purpose communication paths 
between two devices. These connections often are referred to as just Messaging 
Connections. Explicit Messages provide the typical request/response-oriented network 
communications. 


Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 1: Introduction to CIP 


1-3.1 


Object Connection 


I/O Connections 


As previously stated, I/O Connections provide special-purpose communication paths between a 
producing application and one or more consuming applications. Application-specific I/O data 
moves across an I/O Connection. 


I/O Messages are exchanged across I/O connections. An I/O Message consists of a Connection 
ID and associated I/O data. The meaning of the data within an I/O Message is implied by the 
associated Connection ID. The connection end-points are assumed to have knowledge of the 
intended use or meaning of the I/O Message. 


Figure 1-3.1. CIP I/O Connection 
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This document does not define any particular use for I/O Messaging. There are a wide 
variety of functions that can be accomplished using I/O Messaging. Either by virtue of the 
particular type of product transmitting an I/O Message, or based upon configuration performed 
using Explicit Messaging, the meaning and/or intended use of all I/O Messages can be made 
known to the system. See Chapter 6 Device Profiles for I/O message formats defined for 
common device types. 
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Explicit Messaging Connections 


Explicit Messaging Connections provide generic, multi-purpose communication paths between 
two devices. Explicit Messages are exchanged across Explicit Messaging Connections. 
Explicit Messages are used to command the performance of a particular task and to report the 
results of performing the task. Explicit Messaging provides the means by which typical 
request/response oriented functions are performed (e.g. module configuration). 


CIP defines an Explicit Messaging protocol that states the meaning of the message. An Explicit 
Message consists of a Connection ID and associated messaging protocol information. 


Figure 1-3.2. CIP Explicit Messaging Connection 


Explicit Messaging Connection 


Explicit 
A Request Messages iota 
—— (Connection IDs} { Explicit 
& Messaging Messaging 


Protocol) Connection 


Device #2 


Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 1: Introduction to CIP 


1-4 CIP OBJECT MODEL 


Figure 1-4.1 illustrates the abstract object model of a CIP product. Included are the following 
components: 


e Unconnected Message Manager (UCMM) - Processes CIP Unconnected Explicit 
messages. 

e Connection Class- Allocates and manages internal resources associated with both I/O 
and Explicit Messaging connections. 

e Connection Object - Manages the communication-specific aspects associated with a 
particular application-to-application network relationship. 

e Network-Specific Link Object - Provides the configuration and status of a physical CIP 
network connection (eg. DeviceNet and ControlNet objects). 

e Message Router - Distributes Explicit Request Messages to the appropriate handler 
object. 

e Application Objects - Implement the intended purpose of the product. 
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Figure 1-4.1. CIP Module Object Model 
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SYSTEM STRUCTURE 
Topology 


The system structure uses the following physical organization. 


System = { Domain(s) } 

e System contains one or more domains. 

Domain = { Network(s) } 

e A domain is a collection of one or more networks. Networks must be unique within 
a domain. A domain may contain a variety of network types. 

Network = { Subnet(s) } 

e A network is a collection of one or more subnets, where each node’s MAC ID is 
unique on the network. 

Subnet = { Nodes(s) } 

e A subnet is a collection of nodes using a common protocol and shared media access 
arbitration. i.e. subnet may have multiple physical segments and contain repeaters. 

Segment = { Nodes(s) } 

e A segment is a collection of nodes connected to a single uninterrupted section of 
physical media. 

Node = { Object(s) } 

e Anode is a collection of objects which communicate over a subnet, and arbitrates 
using a single MAC ID. A physical device may contain one or more nodes. 
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Figure 1-5.1. System Structure - Topology 
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e Segment Repeater between segments 
e Segments participate in the same media arbitration 


e Subnet Bridge between subnets 


e Duplicate MAC ID check passes through 
e MAC ID’s on one subnet may not be duplicated on the other subnet 
e Subnets may operate at different baud rates 


e Network Router between similar networks 
e Both networks are DeviceNet 


G ae 
e Gateway between dissimilar networks 
e One network is DeviceNet, the other is not 
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1-5.2 Logical Structure 
The system structure uses the following logical elements. 


e Cluster = { Node(s) } 
e Accluster is a collection of nodes which are logically connected. A node may belong 
to one or more clusters. A cluster may span subnets, networks or domains. 


Figure 1-5.2. Clusters 
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Cluster A - Master/Slave Point-to-point Communication (i.e. Poll/Cyclic/COS) 
e A Master and it’s Slaves are a cluster 
e A Master may also be a slave to another Master 
Cluster B - Multicast Master/Slave Communication (i.e. Strobe) 


e A Master and its Slaves are a cluster 


e A Master may also participate with a peer in any cluster 
Cluster C - Peer-to-peer Communication (point-to-point or multicast) 


e Nodes participating in a particular peer-to-peer relationship are a cluster 
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1-6 CIP SPECIFICATION STRUCTURE 


This specification (CIP Common) is the definition of the application and user layers for a 
number of CIP networks. The figure below shows the relationship between the specifications 
of this document and those of the CIP networks. 


Figure 1-6.1 CIP Architecture and Related Specifications 
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DEFINITIONS 


For the purposes of this standard, the following definitions apply. 
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The measure of how frequently a specific connection produces its data. 


To take a resource from a common area and assign that resource for the exclusive use of a 
specific entity. 


Function or data structure for which data is consumed or produced. 


Multiple object classes that manage and provide the run-time exchange of messages across 
the network and within the network device. 


A description of an externally visible characteristic or feature of an object. The attributes of 
an object contain information about variable portions of an object. Typically, they provide 
status information or govern the operation of an object. Attributes may also affect the 
behaviour of an object. Attributes are divided into class attributes and instance attributes. 


Indication of how the object responds to particular events. Its description includes the 
relationship between attribute values and services. 


A format for storage or transmission of binary data in which the most significant bit (or byte) 
comes first. The term comes from "Gulliver's Travels" by Jonathan Swift. The Lilliputians, 
being very small, had correspondingly small political problems. The Big-Endian and Little- 
Endian parties debated over whether soft-boiled eggs should be opened at the big end or the 
little end. See also: little-endian. [Source: RFC1392] 


A unit of information consisting of a 1 ora 0. This is the smallest data unit that can be 
transmitted. 


See octet. 


A set of objects all of which represent a similar system component. A class is a 
generalisation of the object, a template for defining variables and methods. All objects in a 
class are identical in form and behaviour, but they may contain different attribute values. 


A service defined by a particular object class to perform a required function that is not 
performed by a common service. A class specific object is unique to the object class that 
defines it. 


(1) An object that uses the services of another (server) object to perform a task. 
(2) An initiator of a message to which a server reacts. 


Components that manage and provide run-time exchange of messages across the network 
such as the Connection Manager object, the unconnected message manager (UCMM), and 
the Message Router object. 


A logical binding between two application objects. These application objects may be the 
same or different devices. 


Identifier assigned to a transmission that is associated with a particular connection between 
producers and consumers that identifies a specific piece of application information. 


The attribute is made up of a byte stream that defines the application object to which a 
connection instance applies. 


The act of receiving data from a producer. 
A node that is receiving data from a producer. 


The application that consumes data. 


Term used to describe events that repeat in a regular and repetitive manner. 
A physical hardware connection to the link. A device may contain more than one node. 


A collection of device-dependent information and functionality providing consistency 
between similar devices of the same device type. 


A producing or consuming node. 
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One of the communicating entities involved in a connection. 


A discrepancy between a computed, observed or measured value or condition and the 
specified or theoretically correct value or condition. 


The actual physical presentation of an object within a class. Identifies one of many objects 
within the same object class. 


An object that has been created in a device. 


A derived or standard data type, function, function block, program or resource in IEC 1131 - 
programmable controllers. 


Collection of nodes with unique MAC IDs. Segments connected by repeaters make up a 
link; links connected by routers make up a network. 


Describes a model of memory organisation that stores the least significant byte at the lowest 
address. On the network medium, the lowest order byte is transferred first. The native CIP 
data types are sent in little endian order. See appendix C of the CIP Common specification 
for a detailed description of this encoding. 


The object within a node that distributes messaging requests to the appropriate application 
objects. 


A packet with a special destination address, which multiple nodes on the network may be 
willing to receive. [Source: RFC1392] 


A connection from one node to many. Multicast connections allow a single producer to be 
received by many consumer nodes. 


A series of nodes connected by some type of communication medium. The connection paths 
between any pair of nodes can include repeaters, routers and gateways. 


A node’s 32-bit TCP/IP address on the link. In most CIP networks, this network address is 
the MAC ID; however, this is not the case on Ethernet. The DLL of Ethernet has a 48-bit 
MAC ID that is not use directly by the CIP communication stack. 


A connection to a link that requires a single MAC ID. 


(1) An abstract representation of a computer’s capabilities. Objects can be composed of any 
or all of the following components: 

a) data (information which changes with time); 

b) configuration (parameters for behaviour); 

c) methods (things that can be done using data and configuration). 
(2) A collection of related data (in the form of variables) and methods (procedures) for 
operating on that data that have clearly defined interface and behaviour. 


A service defined by a particular object class to perform a required function that is not 
performed by a common service. An object specific service is unique to the object class that 
defines it. 


An octet is 8 bits that indicates no particular data type. 
The client responsible for establishing a connection path to the target. 


A connection that exists between two nodes only. Connections can be either point-to-point 
or multicast. 


A CIP port is the abstraction for a physical network connection to a CIP device. A CIP 
device has one port for each network connection. Note: network specific definitions may 
include additional definitions of this term within the context of the network. 


Act of sending data to a consumer. 
A node that is responsible for transmitting data. 
A system using more than one medium to help prevent communication failures. 


The measure of how frequently the originating application requires the transmission of data 
from the target application. 


A unique 32-bit integer assigned by each manufacturer to every device. The number need 
only be unique with respect to the manufacturer. 


An object that provides services to another (client) object. 
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1-7.49 service Operation or function that an object performs upon request from another object. 
1-7.50 target The end-node to which a connection is established. 
1-7.51 tool An executable software program that interacts with the user to perform some function. 
1-7.52 unconnected The component within a node that transmits and receives unconnected explicit messages and 
message manager sends them directly to the Message Router object. 
(UCMM) 


1-8 ABBREVIATIONS 


For the purposes of this standard, the following abbreviations apply. 


1-8.1 API actual packet interval 

1-8.2. ASCII American Standard Code for Information Interchange 

1-8.3. CIP The control and information protocol defined by the CIP Common Specification. CIP 
includes both connected and unconnected messaging. 

1-8.4 DLL Data Link Layer 

1-8.5 MACID the 48-bit physical address of an Ethernet node 

1-8.6 PDU protocol data unit 

1-8.7 O=T originator to target (used to describe packets that are sent from the originator to the target) 

1-8.8 OSI open systems interconnection (see ISO 7498) 

1-8.9 RPI requested packet interval 

1-8.10 SDU service data unit 

1-8.11 SEM state event matrix 

1-8.12 STD state transition diagram, used to describe object behaviour 

1-8.13 T=>O target to originator (used to describe packets that are sent from the target to the originator) 
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2-1 INTRODUCTION 


CIP is layered on top of a connection-based network. A CIP connection provides a path 
between multiple applications. When a connection is established, the transmissions associated 
with that connection are assigned a Connection ID (CID). If the connection involves a 
bi-directional exchange, then two Connection ID values are assigned. See Figure 2-1.1. 


Figure 2-1.1. Connections and Connection IDs 
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The definition and format of the connection ID is network dependent. For example, the 
connection ID for CIP connections over DeviceNet is based on the CAN Identifier Field. 


2-2 CONNECTION ESTABLISHMENT OVERVIEW 
This section presents an overview of dynamically establishing both Explicit Messaging and I/O 
Connections. 

2-2.1 Explicit Messaging and the UCMM 


The Unconnected Message Manager (UCMM) is responsible for processing Unconnected 
Explicit Requests and Responses. This includes establishing both Explicit Messaging and I/O 
connections. The underlying network defines how the UCMM is accessed and may limit the 
messaging which can occur across the UCMM. 


When using the UCMM to establish an explicit messaging connection, the target application 
object is the Message Router object (Class Code 2). 


Figure 2-2.1 illustrates the steps involved in establishing a Messaging Connection. 
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Figure 2-2.1. Establishing an Explicit Messaging Connection 
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Explicit Messaging Connections are unconditionally point-to-point. Point-to-point connections 
exist between two devices ONLY. The device that requests that the connection be opened (the 
client) is one end-point of the connection, and the module that receives and responds to the 
request (the server) is the other end-point. See Figure 2-2.2. 


Figure 2-2.2. Point-to-Point Nature of Explicit Messaging Connections 
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I/O Connections 


The dynamic process facilitates the establishment of a variety of I/O Connections. This 
specification does not dictate any rules associated with who may perform Connection 


configuration. For example, a tool could interface with two separate devices and create an I/O 
Connection between them. See Figure 2-2.3. 
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Figure 2-2.3. Tool Interface with Devices to Create Connection 
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The tool uses various Explicit Messaging Services to create and configure the I/O Connection 
Objects within the end points. 


I/O connections can be either point-to-point or multicast. Multicast connections allow a single 
transmission to be heard by many nodes. See Figure 2.-2.4. 


2-6 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: 


A message to 


transmit 


Message received 


[optional] 


Release 1.0 


I 
I 
I 
I 
I 
int Be Or Object 
I 
I 
I 
I 
I 
I 
I 


CIP Common Specification Chapter 2: Messaging Protocol 


Figure 2-2.4, Point-to-Point or Multicast Nature of I/O Connections 
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CLIENT AND SERVER CONNECTION END-POINTS 


The terms Client and Server are used throughout this document when discussing the behavior 
associated with a connection end-point. A Client end-point and Server end-point(s) are 
associated with both Explicit Messaging and I/O Connections. The Client is the module that 
originates a transmission, and the Server is the module that reacts to that transmission. The 
Server’s reaction may cause it to return a message to the Client. 
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MESSAGE ROUTER REQUEST/RESPONSE FORMATS 


CIP defines a standard data format for delivering data to and from the Message Router object. 
This data format is used in various places within CIP including the Unconnected Send service 
of the Connection Manager object and the UCMM data structures of most of the CIP networks. 


The Message Router Request Format is defined as: 


Parameter Name Data Type | Description 

Service USINT Service code of the request. 

Request_Path Size | USINT The number of 16 bit words in the Request_Path field (next element). 

Padded _ 
Request_Path EPATH This is an array of bytes whose contents convey the path of the request 
(Class ID, Instance ID, etc.) for this transaction. 

Request_Data Array of Service specific data to be delivered in the Explicit Messaging Request. 

octet If no additional data is to be sent with the Explicit Messaging Request, 


then this array will be empty. 


The Message Router Response F 


ormat is defined as: 


Parameter Name Data Type | Description 
Reply Service UINT Reply service code. 
Reserved USINT Shall be zero. 
USINT . ; ; 
General Status One of the General Status codes listed in Appendix B (Status Codes). 
Size of Additional USINT Number of 16 bit words in Additional Status array. 
Status 
Additional Status Array of Additional status. 
UINT 
Response Data Atray of Response data from request or additional error data if General Status 
octet indicated an error. 
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INTRODUCTION 


The CIP Communication Objects manage and provide the run-time exchange of messages. The 
Services, Attributes, and Behaviors associated with the Communication Objects are detailed in 
this Chapter. Part of an object definition involves assigning a Data Type to an attribute. See 
Appendix C for a detailed description of CIP Data Types and Data Management. 


Important: It is not the intent of the following sections to specify any particular internal 
implementation. 


The Communication Object Classes are defined by describing: 


e Object Class Attributes 

e Object Class Services 

e Object Instance Attributes 
e Object Instance Services 
e Object Instance Behavior 


Each CIP connection is represented by a Connection Object (Class code 0x05). The creation of 
this communication object resource can be done in one of two ways. Each subnet type defines 
which method shall be used. The two methods are: 


e Use of the Create service (Service code 0x08) for the Connection Object 
e Use of the Forward Open service for the Connection Manager Object 


Creating Connections Through the Connection Object 


When the subnet defines that connections are created through the Connection Object, a CIP 
device shall support the Create service for this class. The Create service instantiates a 
Connection Instance with attribute values defaulted as defined by the class. The connection 
instance is configured through individual access to each Connection instance attribute. A 
separate service request (Apply Attributes, Service code 0x0D) is needed to transition the 
connection to the Established state. 


Creating Connections Through the Connection Manager Object 


When the subnet defines that connections are created through the Connection Manager Object, 
a CIP device shall support the Forward Open service of this class. When successful, the 
Connection Manager instantiates an instance of the Connection class. This connection instance 
is configured with the values sent in the Forward Open service and is transitioned to the 
established state. This single CIP service request is modeled internally as a single Connection 
Class service request (using the Create service) and several internal service requests (using the 
Set Attribute Single and Apply Attributes services). A device supporting connection creation 
through the Connection Manager may or may not provide external visibility to the Connection 
Class instances. 
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3-2 LINK PRODUCER OBJECT CLASS DEFINITION 


The Link Producer Object is the component responsible for the low-level transmission of data. 


Important: NO externally visible interface to the Link Producer Class across Explicit 
Messaging Connections exists. All services/attributes noted in the following sections describe 
internal behavior. These services/attributes are accessed via attributes and services of the 
Connection Object. 


3-2.1 Link Producer Object Class Attributes 
There are no Link Producer Class Attributes. 


3-2.2 Link Producer Object Class Services 
The services supported by the Link Producer Class are listed below. 


e Create - Used internally to instantiate a Link Producer Object 
e Delete - Used internally to deletes a Link Producer Object 


3-2.3 Link Producer Object Instance Attributes 
The following list describes the Link Producer Instance attributes. 


e USINT state - The current state of the Link Producer instance. Possible states include 
the following: 


Table 3-2.1. Link Producer States 


State Name Description 


Non-existent The Link Producer has yet to be instantiated 


Running The Link Producer has been instantiated and is waiting to be told to 


transmit via the invocation of its Send service. 


e UINT connection_id - The value placed within the CAN Identifier Field when this 
Link Producer is triggered to send. The Connection Object using this Link Producer 
internally initializes this attribute with the value in its produced_connection_id 
attribute. See section 3-4.3, Connection Instance Attributes for a definition of the 
produced_connection_id attribute. 


3-2.4 Link Producer Object Instance Services 
The services supported by a Link Producer Object Instance are listed below. 


e Send - Used internally to tell the Link Producer to transmit data onto the subnet. 
e Get_Attribute - Used internally to read a Link Producer Object attribute 
e Set_Attribute - Used internally to modify a Link Producer Object attribute 


3-2.5 Link Producer Instance Behavior 
Figure 3-2.2 and Table 3-2.3 illustrate the Link Producer’s Instance behavior. 
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Figure 3-2.2. Link Producer in Object State Transition 
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Table 3-2.3. State/Event Matrix: Link Producer 
Event State 
Non-Existent Running 
Class Create invoked internally Class instantiates Link Producer | Not applicable 


Object. Link Producer enters the 
Running state. 


Class Delete invoked internally Error: Instance Not Present Release all associated instance 
resources. Transition to the 
Non-existent state. 


Send invoked internally Error: Instance Not Present Transmit the data 
Set_Attribute invoked internally Error: Instance Not Present Modify the attribute 
Get_Attribute invoked internally Error: Instance Not Present Return the attribute value 
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3-3.2 


3-3.3 


3-3.4 


3-3.5 
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LINK CONSUMER OBJECT CLASS DEFINITION 
The Link Consumer Object is the component responsible for the low-level reception of 
messages. 


Important: NO externally visible interface to the Link Consumer Class across Explicit 
Messaging Connections exists. All services/attributes noted in the following sections describe 
internal behavior. These services/attributes are accessed via attributes and services of the 
Connection Object. 


Link Consumer Object Class Attributes 


There are no Link Consumer Class Attributes. 


Link Consumer Class Services 
The services supported by the Link Consumer Class are listed below. 
e Create - Used internally to instantiate a Link Consumer Object 
e Delete - Used internally to deletes a Link Consumer Object 
Link Consumer Instance Attributes 
The following list describes the Link Consumer Instance attributes. 
e USINT state - The current state of the consumer instance. Possible states include: 


Table 3-3.1. Link Consumer States 


State Name Description 


Non-existent The Link Consumer has yet to be instantiated. 


Running The Link Consumer has been instantiated and is waiting to receive a message. 


e UINT connection_id - This attribute holds the CAN /dentifier field value that denotes 
the message to be received by this consumer. The Connection Object utilizing this Link 
Consumer internally initializes this attribute with the value in its 
consumed_connection_id attribute. See section 3-4.3, Connection Instance Attributes 
for a definition of the consumed _connection_id attribute. 


Link Consumer Instance Services 
The services supported by a Link Consumer Object Instance are listed below. 


e Get_Attribute - Used internally to read a Link Consumer Object attribute 
e Set_Attribute - Used internally to modify a Link Consumer Object attribute 


Link Consumer Instance Behavior 
Figure 3-3.2 and Table 3-3.3 illustrate the Link Consumer’s Instance behavior. 
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Figure 3-3.2. Link Consumer Object State Transition Diagram 
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Table 3-3.3. State/Event Matrix: Link Consumer 


Event State 
Running 
Class Create invoked internally Class instantiates Link Consumer | Not applicable 


Object. Link Consumer enters the 
Running state. 


Class Delete invoked internally Error: Instance Not Present Release all associated instance 
resources. Transition to the 
Non-existent state. 


Data received Not applicable Deliver data to the associated 
Connection Object by invoking its 
Receive_Data() service 


Set_Attribute invoked internally Error: Instance Not Present Modify the attribute 
Get_Attribute invoked internally Error: Instance Not Present Return the attribute value 
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CONNECTION OBJECT CLASS DEFINITION 
Class Code: 5 


The Connection Class allocates and manages the internal resources associated with both I/O 
and Explicit Messaging Connections. The specific instance generated by the Connection Class 
is referred to as a Connection Instance or a Connection Object. 


Unless otherwise noted, all services/attributes noted in the following sections are accessible 
using Explicit Messaging. 


A Connection Object within a particular module actually represents one of the end-points of a 
Connection. It is possible for one of the Connection end-points to be configured and “active” 
(e.g. transmitting) without the other end-point(s) being present. Connection Objects are used to 
model the communication specific characteristics of a particular Application-to-Application(s) 
relationship. 


A specific Connection Object Instance manages the communication-specific aspects related to 
an end-point. A CIP Connection Object uses the services provided by a Link Producer and/or 
Link Consumer to perform low-level data transmission and reception functions. 


Figure 3-4.1. Connection Object & Link Producer/Consumer Relationship 
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Connection Object Class Attributes 


The Connection Class attributes are defined below in Table 3-4.2. 


Table 3-4.2. Connection Class Attributes 
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Connection Object Class Services 


The Connection Class supports the following CIP Common Services: 


Table 3-4.3. Connection Class Services 


Service Need In Service Name Service Description 
Code _ | Implementation 


O8nex Optional Used to instantiate a Connection Object 

O9 hex Optional Delete Used to delete all Connection Objects (independent of state) and to 
release all associated resources. When the Delete service is sent to 
the Connection Class (Instance ID set to zero (0)) versus a specific 
Connection Object Instance, then ALL Instances are deleted. 

O5 hex Optional Reset Used to reset all resettable Connection Objects. The conditions 
under which a Connection is resettable are listed in the State Event 
Matrix in section 3-4.6 

1 Lnex Optional Find _Next_ | Used to search for Instance IDs associated with existing Connection 

Object_Instance | Objects. The Connection Class returns the Instance ID associated 


with any Connection Object not in the Non-Existent state. 


OE nex Conditional Get_Attribute_ | Used to read a Connection Class attribute value. This service is 
Single Required if any of the Connection Class Attributes are supported. 


Connection Object Instance Attributes 


The following list provides a summary of the Connection Instance attributes and their 
associated data types. 


Table 3-4.4. Connection Object Instance Attributes 


Attr ID Need In Attribute Name Data Brief Description of Attribute 
Implementation Type 


USINT | State of the object 
USINT | Indicates either I/O or Messaging Connection 
TransportClass_trigger BYTE | Defines behavior of the Connection 


UINT | Placed in CAN Identifier Field when the 
connection_id Connection transmits on a DeviceNet subnet 
5 Conditional | DeviceNet_consumed_ UINT | CAN Identifier Field value that denotes 
connection_id message to be received on a DeviceNet 
subnet. 


6 Required DeviceNet_initial_ comm_ Defines the Message Group(s) across which 
characteristics productions and consumptions associated 

with this Connection occur on a DeviceNet 
subnet. 

7 Produced_connection_size Maximum number of bytes transmitted 
across this Connection 

8 UINT | Maximum number of bytes received across 
this Connection 

9 UINT | Defines timing associated with this 
Connection 


10 Conditional CIP_produced_connection_i | UDINT | Identifies the message sent on the subnet by 
d this connection. 

ia Conditional CIP_consumed_connection_i| UDINT | Identifies the message received from the 
d subnet for this connection. 


12 Watchdog_timeout_action USINT | Defines how to handle Inactivity/Watchdog 
timeouts 


Blwlmle 
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Attr ID Brief Description of Attribute 
Implementation Type 
13 Required Produced_connection_path_ Number of bytes in the 
Ca] length produced_connection_path attribute 
14 Required Produced connection path | Packed | Specifies the Application Object(s) whose 
| data is to be produced by this Connection 
Object. See Appendix C. 
_ length consumed_connection_path attribute 
16 Required Consumed_connection_path | Packed | Specifies the Application Object(s) that are to 
EPATH | receive the data consumed by this 
Connection Object. See Appendix C. 


17 Conditional | Production_inhibit_time UINT | Defines minimum time between new data 
production. This attribute is required for all 


I/O Client connections, except those with a 
production trigger of Cyclic. 


Important: Access Rules for the Connection Object Instance Attributes are defined in section 
3-4.7. 


The list below provides detailed descriptions of the Connection Object Instance Attributes. 
The defined default attribute values are to be used when no other internal and/or 
system-defined rules exist. 


state Attribute - USINT data type 


This attribute defines the current state of the Connection instance. Table 3-4.5 defines the 
possible states and assigns a value used to indicate that state. Also see figure 3-4.27 and figure 
3-4.31 for state transition behavior. 


Table 3-4.5. Values assigned to the state attribute 


Value State Name Description 
00 Non-existent The Connection has yet to be instantiated 


01 Configuring The Connection has been instantiated and is waiting for the following events to 
occur: (1) to be properly configured and (2) to be told to apply the configuration. 


02 Waiting For The Connection instance is waiting exclusively for its consumed_connection_id 
7 2 : i : 
Connection ID” | and/or produced connection id attribute to be set. 


03 Established The Connection has been validly/fully configured and the configuration has been 
successfully applied. 
04 Timed Out If a Connection Object experiences an Inactivity/Watchdog timeout, then a 


transition may be made to this state. See the watchdog_timeout_action attribute 
description and the description of the Inactivity/Watchdog Timer (section 3-4.4) for 
more details. 


05 Deferred Delete” | If an Explicit Messaging Connection Object experiences an Inactivity/Watchdog 
timeout, then a transition may be made to this state. See the 

watchdog _timeout_action attribute description and the description of the 
Inactivity/Watchdog Timer (section 3-4.4) for more details. 


06 Closing A CIP Bridged connection object has received, and is processing, a Forward Close 
from the Connection Manager. The deletion of the connection does not occur until 
after a successful Forward Open response has been received from the target node. 
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Value State Name Description 


1 When the Connection instance attributes are applied it may not be possible for the module to generate the 
produced_connection_id and/or consumed_connection_id values (see initial comm_characteristics attribute for 
rules). If this is the case then all the tasks required to apply the attributes are performed except for the 
initialization of these attributes within the Connection and associated Link Producer/Consumer Objects and a 
transition is made to this state. In this state the Connection instance is waiting exclusively for its 
produced_connection_id and/or consumed_connection_id attributes to be set. 


This value is only used on DeviceNet. 


Important: A dynamically created connection instance is the child of the Explicit Messaging 
connection across which it was created. 


Important: All resources associated with a Connection Instance (A) that has been dynamically 
created across an Explicit Messaging Connection (B) must be released if the Explicit 
Messaging Connection (B) breaks down prior to the dynamically created Connection Instance 
(A) transitioning to the Established state. 


Important: When a transition is made to the Established state, all timers associated with the 
Connection Object are activated (see section 3-4.4, Connection Timing) 


instance_type Attribute - USINT data type 
This attribute defines the instance type. See Table 3-4.6. 


Table 3-4.6. Values assigned to the instance_type attribute 
Value Meaning 
00 Explicit Messaging. This Connection Instance represents one of the end-points of an Explicit 


Messaging Connection. An Explicit Messaging Connection is dynamically created by sending the 
Open Explicit Messaging Connection Request to the Connection Class. 

01 I/O. This Connection Instance represents one of the end-points of an I/O Connection. An I/O 
Connection is dynamically created by sending a Create Request to the Connection Class. 


02 CIP Bridged. This Connection Instance represents an intermediate ‘hop’ of a bridged I/O or Explicit 
Messaging connection. A pair of CIP Bridged connection objects (one for each subnet bridged 
between) are dynamically created by a node after successfully receiving a Forward Open service to 


the Connection Manager object when this node is not the end point (target). See Chapter 10 for 
additional information. 
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3-4.3.3.  transportClass_trigger Attribute - USINT data type 
Defines whether this is a producing only, consuming only, or both producing and consuming 
connection. If this end point is to perform a data production, this attribute also defines the event 
that triggers the production. The eight (8) bits are divided as follows: 


transportClass_trigger 


Dir Production Transport 
Trigger Class 


Transport Class 
0 = Class 0 
1 = Class 1. 
2 = Class 2. 
3 = Class 3. 
Production Trigger 
0 = Cyclic 
1 = Change-Of-State 
2 = Application Object 


Direction 

0 = Client 

1 = Server 
The Direction bit of the transportClass_trigger byte indicates whether the end-point is to 
act as the Client or the Server on this connection. The following values are defined: 


Table 3-4.7. Possible Values within Direction Bit 
Value Meaning 
0 Client This end-point provides the Client behavior associated with this Connection. 


Additionally, this value indicates that the Production Trigger bits within the 
transportClass_trigger byte contain the description of when the Client is to produce the 
message associated with this connection. Client connections with production trigger 
value of 0 or 1 (Cyclic or Change-of-State) shall produce immediately after 
transitioning to the Established state. 

This end-point provides the Server behavior associated with this Connection. In 
addition, this value indicates that the Production Trigger bits within the 
transportClass_trigger byte are to be IGNORED. The Production Trigger bits are 
ignored due to the fact that a Server end-point reacts to the transmission from the 
Client. The only means by which a Server end-point is triggered to transmit is when 
this reaction calls for the production of a message (Transport Classes 2 or 3). 


The following table lists the values that are possible within the Production Trigger bits of the 
transportClass_trigger attribute. 


Table 3-4.8. Possible Values within Production Trigger Bits 
If the Then the Production of a message is: 
value is: 
0 The expiration of the Transmission Trigger Timer triggers the data production. See 
section 3-4.4, Connection Timing for a detailed description of the Transmission Trigger 
Timer. 
1 Change-Of- | Production occurs when a change-of-state is detected by the Application Object. Note 


State that the consuming end-point may have been configured to expect the packet at a certain 
rate, regardless of the triggering mechanism at the producing end-point. See the 
description of the expected_packet_rate attribute of a Connection Object and the 
description of Connection Timing in section 3-4.4 for more information. 
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If the 
value is: 


Then the Production of a message is: 


Application | The Application Object decides when to trigger the production. Note that the consuming 
Object end-point may have been configured to expect the packet at a certain rate, regardless of 
Triggered | the triggering mechanism at the producing end-point. See the description of the 
expected_packet_rate attribute of a Connection Object and the description of 
Connection Timing in section 3-4.4 for more information. 
Reserved by CIP 


Table 3-4.9 lists possible values within the Transport Class nibble of the 
transportClass_trigger attribute. Behaviors resulting from these particular values are 
illustrated in the series of figures that follow the table. 


Table 3-4.9. Possible Values within Transport Class Bits 


Value Meaning 


0 Transport Class 0 Based on the value within the Dir bit, this connection end-point will be a 
producing only OR consuming only end-point. Upon application of this 
Connection instance, the module instantiates either a Link Producer (Dir bit = 


Client, producing only) or a Link Consumer (Dir bit = Server, consuming 
only) to be associated with this Connection. 


2 Indicates that the module will both produce AND consume across this 

connection. The Client end-point generates the first data production that is 
consumed by the Server, which causes the Server to return a production that is 
consumed by the Client. 


1 Transport Class 1 


3 Transport Class 3 


4 Transport Class 4 Non-blocking 


5 Transport Class 5 Non-blocking, fragmenting 


6 Transport Class 6 Multicast, fragmenting 


7-F Reserved 


A 16-bit sequence count value is prepended to all Class 1, 2, and 3 transports. This value is 
used to detect delivery of duplicate data packets. Sequence count values are initialized on the 
first message production and incremented on each subsequent new data production. A resend 
of old data shall not cause the sequence count to change, and a consumer shall ignore data 
when it is received with a duplicate sequence count. Consuming applications can use this 
mechanism to distinguish between new samples and old samples that were sent to maintain the 
connection. 


The following tables and figures illustrate the valid combinations of Production Trigger and 
Transport Class and provides a description of the Client and Server behaviors. See section 3- 
4.4 for a description of the Transmission Trigger Timer, which is shown in the illustrations. 
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3-4.3.3.1 Server Transport Class 0 and 1 Behavior 
Figure 3-4.10. Server Transport Class 0 and 1 Behavior 


Direction Production Transport 
i Trigger Bits Class Bits Meaning 


X (ignored) = a Server Transport Class 0. 


X (ignored) 1 Server Transport Class 1. The message 
received is prepended with a 16-bit 
sequence count value. 


Server Transport 
Class 0 and 1 Connection Object 


@ 


Message received 


Application 


If Class 1 transport and the sequence count is the 
same as the previous message, notify the 
application that a duplicate message was received 
and discard data. Otherwise, the application is 
notified that consumption has occurred. 
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3-4.3.3.2. Server Transport Class 2 Behavior 


Figure 3-4.11. Server Transport Class 2 Connection Object 


Direction | Production | Transport 
Bit Trigger Bits | Class Bits Meaning 


X (ignored) 2 Server Transport Class 2. The act of consumption by the Link 
Consumer IMMEDIATELY triggers the associated Link Producer 
to transmit without intervention by the application. The message 
received is prepended with a 16-bit sequence count value. The 
message returned is prepended with this same 16-bit sequence 
count value. 
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3-4.3.3.3 Server Transport Class 3 Behavior 


Figure 3-4.12. Server Transport Class 3 Behavior 


Direction | Production | Transport 
Bit Trigger Bits | Class Bits Meaning 


X (ignored) 3 Server Transport Class 3. When the Link Consumer receives a 
message, it delivers it to the Application Object specified within the 
consumed_connection_path attribute. The Application Object 
then validates this receive data event (illustrated as #2 in the figure 
below). If the Application Object determines that the receive data 
event is valid, then it is REQUIRED to trigger a production as 
illustrated below. If the Application detects an error, then it may or 
may not trigger a production based on its own internal logic. The 
message received is prepended with a 16-bit sequence count 
value. The message returned is prepended with this same 16- 
bit sequence count value. 
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3-4.3.3.4 Client Transport Class 0 and 1 Behavior: Cyclic 
Figure 3-4.13. Client Transport Class 0 and 1 Behavior: Cyclic 
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3-4.3.3.5 Client Transport Class 2 and 3 Behavior: Cyclic 
Figure 3-4.14. Client Transport Classes 2 & 3 Behavior: Cyclic 
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3-4.3.3.6 Client Transport Class 0 and 1 Behavior: Change-Of-State 
Figure 3-4.15. Client Transport Class 0 and 1 Behavior: Change-Of-State 
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3-4.3.3.7 Client Transport Class 2 and 3 Behavior: Change-Of-State 
Figure 3-4.16. Client Transport Classes 2 & 3 Behavior: Change-Of-State 
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3-4.3.3.8 Client Transport Class 0 and 1 Behavior: Application Object Triggered 
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Figure 3-4.17. Client Transport Class 0 and 1 Behavior: Application Object Triggered 
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Client Transport Class 2 and 3 Behavior: Application Object Triggered 
Figure 3-4.18. Client Transport Classes 2 & 3 Behavior: Application Object Triggered 
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To summarize, refer to the following table for the valid values within the 
transportClass_trigger attribute of a Connection Instance: 


TransportClass_trigger 


bits Meaning 

1 xxx 0000 Direction = Server, Production Trigger = IGNORED, Transport Class = 0. 

1 xxx 0001 Direction = Server, Production Trigger = IGNORED, Transport Class = 1. 

1 xxx 0010 Direction = Server, Production Trigger = IGNORED, Transport Class = 2. 

1 xxx 0011 Direction = Server, Production Trigger = IGNORED, Transport Class = 3. This is the value 

assigned to this attribute within the Server end-point of a Explicit Messaging Connection. 

0 000 0000 Direction = Client, Production Trigger = Cyclic, Transport Class = 0. 

0 000 0001 Direction = Client, Production Trigger = Cyclic, Transport Class = 1. 

0 000 0010 Direction = Client, Production Trigger = Cyclic, Transport Class = 2. 

0 000 0011 Direction = Client, Production Trigger = Cyclic, Transport Class = 3. 

0 001 0000 Direction = Client, Production Trigger = Change-Of-State, Transport Class = 0. 

0 001 0001 Direction = Client, Production Trigger = Change-Of-State, Transport Class = 1. 

0 001 0010 Direction = Client, Production Trigger = Change-Of-State, Transport Class = 2. 

0001 0011 Direction = Client, Production Trigger = Change-Of-State, Transport Class = 3. 

0 010 0000 Direction = Client, Production Trigger = Application Object, Transport Class = 0. 
0.010 00001 Direction = Client, Production Trigger = Application Object, Transport Class = 1 

0 010 0010 Direction = Client, Production Trigger = Application Object, Transport Class = 2. 

0010 0011 Direction = Client, Production Trigger = Application Object, Transport Class = 3. This is the 

value assigned to this attribute within the Client end-point of a Explicit Messaging Connection. 

11111111 Default value assigned to this attribute within an I/O Connection. 


UINT DeviceNet_produced_connection_id 


Contains the DeviceNet Connection ID to be associated with transmissions sent across this 
connection (if any). This is the value that will be specified in the CAN Identifier Field when 
this Connection transmits. See chapter 3, section 3-2, DeviceNet’s Use of the CAN Identifier 
Field. This value is loaded directly into the associated Link Producer’s connection_id attribute. 
The following values are defined: 


Table 3-4.18. Values defined for the produced_connection_id attribute 


Value Meaning 
0 - 7FOnex The value to be placed in the CAN Identifier Field when this Connection transmits. 
800nex - FFFE;., | Reserved by CIP 
FFFF jx Default value assigned to this attribute within an I/O Connection. This attribute will 


retain this value if this Connection instance is not producing any data (consumer only). 


UINT DeviceNet_consumed_connection_id 


Contains the Connection ID, which identifies messages to be received across this connection (if 
any). This is the CAN Identifier Field value that is associated with messages this Connection 
Object receives. See chapter 3, section 3-2, DeviceNet’s Use of the CAN Identifier Field. This 
value is loaded directly into the associated Link Consumer’s connection_id attribute. The 
following values are defined: 
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Table 3-4.19. Values defined for the consumed_connection_id attribute 


Value Meaning 


0 - 7FObex The value that identifies messages to be consumed. This will be specified in the 
CAN Identifier Field of messages that are to be consumed. 


800nex - FFFEnex | Reserved by CIP 


FFFFhex Default value assigned to this attribute within an I/O Connection. This attribute will 
retain this value if this Connection Instance is not consuming any data (producer 


only). 


3-4.3.6 USINT DeviceNet_initial_comm_characteristics 


Defines the Message Group(s) across which productions and consumptions associated with this 
Connection occur. This byte is divided into two nibbles. 


Figure 3-4.20. DeviceNet_initial_comm_characteristics attribute format 


7tots}alaftatifo 


Initial Production Initial Consumption 
Characteristics Characteristics 


The following table lists the values that are possible within the Jnitial Production 
Characteristics nibble (upper nibble) of the initial_comm_characteristics attribute. 


Table 3-4.21. Values for the Initial Production Characteristics Nibble 


Value Meaning 


0 Produce across Message Group | | The production associated with this Connection is to take place across 
Message Group |. The producing module generates the Connection ID 
value and loads it into the Connection Object’s produced_connection_id 
attribute. The producing module allocates a Message ID from its Group 1 
Message ID pool and combines this with its Source MAC ID to generate 
the Connection ID. The numerically lowest available Group 1 Message ID 
is to be used in generating the produced_connection_id attribute value. 
This value must also be loaded into the corresponding 
consumed_connection_id attribute(s) associated with the consuming 
Connection Object(s). 


1 Produce across Message Group 2 | The production associated with this Connection is to take place across 
(Destination) Message Group 2. Additionally, the intended recipient’s MAC ID 
(Destination MAC ID) is to be placed within the MAC ID component of 
the Group 2 Identifier Field. In this case, the consuming module generates 
the Connection ID value to be associated with transmissions across this 
connection. When the consuming module has generated this value and 
loaded it into the appropriate Connection Object’s 
consumed_connection_id attribute, it can be read and subsequently loaded 
into the producing Connection Object’s produced_connection_id attribute. 


2 Produce across Message Group 2 | The production associated with this Connection is to take place across 
(Source) Message Group 2. In addition, the producing module’s MAC ID (Source 
MAC ID) is to be placed within the MAC ID component of the Group 2 
Identifier. In this case, the producing module generates the Connection ID 
value and loads it into the Connection Object’s produced_connection_id 
attribute. The numerically lowest available Group 2 Message ID is to be 
used in generating the produced_connection_id attribute value. This value 
must also be loaded into the corresponding consumed_connection_id 
attribute(s) associated with the consuming Connection Object(s). 
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Value Meaning 


3 Produce across Message The production associated with this Connection is to take place across 

Group 3 Message Group 3. The producing module generates the Connection ID 
value and loads it into the Connection Object’s produced_connection_id 
attribute. The producing module allocates a Message ID from its Group 3 
Message ID pool and combines this with its Source MAC ID to generate 
the Connection ID. The numerically lowest available Group 3 Message ID 
is to be used in generating the produced_connection_id attribute value. 
This value must also be loaded into the corresponding 
consumed_connection_id attribute(s) associated with the consuming 
Connection Object(s). 


F Default value The default value assigned to the Initial Production Characteristics nibble 
within an I/O Connection. Note that if this is a consuming only I/O 
Connection, then the default value remains in this nibble. Explicit 
Messaging Connection Objects automatically configure this attribute when 
the Connection is established. 


Table 3-4.22 lists the possible values within the Initial Consumption Characteristics nibble 
(lower nibble) of the DeviceNet_initial_comm_characteristics attribute. 


Table 3-4.22. Values for the Initial Consumption Characteristics Nibble 


Meaning 
Value 


0 Consume a Group | Message | The message to be consumed will be transmitted across Message Group |. The 
producing module generates the Connection ID value. This value must be loaded 
into the consumed_connection_id attribute associated with the consuming 
Connection Object(s). 
1 Consume a Group 2 Message _ | The message to be consumed will be transmitted across Message Group 2. The 
(Destination) intended recipient’s MAC ID (Destination MAC ID) is specified within the Group 2 
Identifier. The consuming module generates the Connection ID value and loads it 
into the consumed_connection_id attribute associated with this Connection Object. 
The numerically lowest available Group 2 Message ID is to be used in generating the 
consumed_connection_id attribute value. This value must be loaded into the 
producing Connection Object’s produced_connection_id attribute. 
2 Consume a Group 2 Message_ | The message to be consumed will be transmitted across Message Group 2. The 
(Source) transmitting module’s MAC ID (Source MAC ID) is specified within the Group 2 
Identifier. In this case, the producing module generates the Connection ID value and 
loads it into the Connection Object’s the produced_connection_id attribute. This 
value must be loaded into the consumed_connection_id attribute associated with the 
consuming Connection Object(s). 


3 Consume a Group 3 Message _| The message to be consumed will be transmitted as a Group 3 Message. The 
producing module generates the Connection ID value. The Connection ID value 
must be loaded into this Connection Object’s consumed_connection_id attribute. 

4 - E | Reserved by CIP 


F Default value The default value assigned to the Initial Consumption Characteristics nibble within 
an I/O Connection. Note that if this is a producing only \/O Connection, then the 
default value remains in this nibble. Explicit Messaging Connections automatically 
configure this attribute when the Connection is established. 


Important: The module that generates a Connection ID must guarantee that it does not allocate 
the Message ID/MAC ID pair in such a way that two separate modules are capable of 
transmitting identical bit patterns within the Identifier Field. Refer to section 3-4.8, Dynamic 
Management of Message IDs. 
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UINT produced_connection_size 


The meaning of this attribute is different for Explicit Messaging Connections than it is for I/O 
Connections. 


For Explicit Messaging Connections: 


This attribute signifies the maximum number of Message Body bytes that a module is able 
to transmit across this Connection (the Message Body begins with the Service Field and 
ends with the last Service Specific data byte). 

Modules that do not support the transmission of the Fragmentation Protocol initialize this 
attribute to the value 7 (Message Header (1 byte) + Message Body (7 bytes) = 8 bytes, 
which is the maximum length of a non-fragmented Explicit Message). Modules that cannot 
or do not predefine an up-front transmit limit load, place the value Oxffff into this attribute 
(there may still be a limit, however, it is not known in advance). Modules that support the 
Fragmentation Protocol, but place a known limit on the maximum amount of Message 
Body bytes that can be transmitted in a single fragmented series initialize this attribute 
accordingly. 


Important: Due to the nature of Explicit Messaging, the length of Explicit Messages will 
fluctuate over the lifetime of a connection. Explicit Messaging Connections perform 
fragmentation based on the /ength of the current message to transmit. 


For /O Connections: 


If the transportClass_trigger indicates that this Connection instance is to produce, then 
this attribute defines the maximum amount of I/O data that may be produced as a single unit 
across this connection. The amount of I/O to be transmitted at any given point in time can 
be less than or equal to the connection_size attribute. 


This attribute defaults to zero (0) within an I/O Connection. If this attribute is set to a value 
greater than eight (8) in an I/O Connection, then the Connection will break up the data into 
multiple fragments. 


Important: Fragmentation within I/O Connections is performed based on the value within this 
attribute, regardless of the current amount of data to transmit. 


Important: I/O Messages that contain no Application I/O Data and were configured to contain 
data (via produced_connection_size being greater than zero (0)) are defined to indicate a No 
Data event for the receiving Application Object(s). The behavior of an Application Object 
upon detection of the No Data event is Application Object specific. 


UINT consumed_connection_size 


The meaning of this attribute is different for Explicit Messaging Connections than it is for I/O 
Connections. 


For Explicit Messaging Connections: 
This attribute signifies the maximum number of Message Body bytes that this module is 


able to receive across this Connection (the Message Body begins with the Service Field and 
ends with the last Service Specific data byte). 
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Modules that do not support the reception of the Fragmentation Protocol initialize this to the 
value 7 (Message Header (1 byte) + Message Body (7 bytes) = 8 bytes, which is the 


maximum length of a non-fragmented Explicit Message). Modules that cannot or do not 
predefine an up-front receive limit load, place the value Oxffff into this attribute (there may 
still be a limit - it is just not known in advance). Modules that support the Fragmentation 
Protocol, but place a known limit on the maximum amount of Message Body bytes that can 
be received in a single fragmented series, initialize this attribute accordingly. Because of the 
nature of Explicit Messaging, the length of Explicit Messages will fluctuate over the 
lifetime of a connection. 


For I/O Connections: 


If the transportClass_trigger attribute indicates that this Connection is to consume, then 
this attribute defines the maximum amount of data that may be received as a single unit 
across this connection. The actual amount of I/O data received at any given time can be less 
than or equal to the connection_size attribute. 


This attribute defaults to zero (0) within an I/O Connection. If this attribute is set to a value 
greater than eight (8) in an J/O Connection, then the Connection will process the 
fragmentation protocol. 


The length of an I/O Message must be less than or equal to this attribute for an I/O 
Connection Object to receive it as a valid message. If an I/O Connection Object receives a 
message whose length is greater than this attribute, then it immediately discards the message 
and discontinues any subsequent processing. Note that with respect to the Server end-point 
of a Transport Class 2 or 3 Connection, this too much data error condition results in no 
response being transmitted and the watchdog timer is not kicked. 


UINT expected_packet_rate 


This attribute is used to generate the values loaded into the Transmission Trigger Timer and the 
Inactivity/Watchdog Timer. See section 3-4.4, Connection Timing, for a description of the 
Transmission Trigger and Inactivity/Watchdog timers. 


The resolution of this attribute is in milliseconds. A request to configure this attribute may 
result in the specification of a time value that a product cannot meet. In addition to 
performing product specific range checking when a request to modify this attribute is 
received, the following steps are performed: 


e Ifthe specified value is not equal to an increment of the available clock resolution, then 
the value is rounded up to the next serviceable value. For example: a 
Set_Attribute_Single request is received specifying the value 5 for the 
expected_packet_rate attribute and the product provides a 10 millisecond resolution on 
timers. In this case the product would load the value 10 into the expected_packet_rate 
attribute. 

e The value that is actually loaded into the expected_packet_rate attribute is reported in 
the Service Data Field of a Set_Attribute Single response message associated with a 
request to modify this attribute. 

e Ifthe requested value is equal to an increment of the clock resolution, then the 
requested value is loaded into the expected_packet_rate and reported in the response. 
For example: if the value 100 is requested and the clock resolution is 10 milliseconds, 
then of a value of 100 is loaded. 
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When a Connection Object is in the Established state, any modifications to the 
expected_packet_rate attribute have immediate effect on the Inactivity/Watchdog 
Timer. The following steps are performed by a Connection Object in the Established 
state when a request is received to modify the expected_packet_rate attribute: 


e the current Inactivity/Watchdog Timer is canceled 
e anew Inactivity/Watchdog Timer is activated based on the new value in the 
expected_packet_rate attribute. 


This attribute defaults to 2500 (2500 milliseconds) within Explicit Messaging 
Connections, and to zero (0) within an I/O Connection. 


CIP_produced_connection_id 


Contains the Connection ID which identifies messages to be sent across this connection (if 
any). 


CIP_consumed_connection_id 


Contains the Connection ID which identifies messages to be received across this connection (if 
any). 


USINT watchdog_timeout_action 


This attribute defines the action the Connection Object should perform when the 
Inactivity/Watchdog Timer expires. The table below defines the specifics of this attribute. 


Table 3-4.23. Values for the watchdog_timeout_action 


Value Meaning 


0 Transition to Timed Out. The Connection transitions to the Timed Out state and remains 
in this state until it is Reset or Deleted. The command to Reset or Delete could come from 
an internal source (e.g., an Application Object) or could come from the network (e.g., a 
configuration tool). This is the default value for this attribute with respect to I/O 
Connections. This value is invalid for Explicit Messaging Connections. 


1 Auto Delete. The Connection Class automatically deletes the Connection if it experiences 
an Inactivity/Watchdog timeout. This is the default value for this attribute with respect to 
Explicit Messaging Connections. 


2 Auto Reset. The Connection remains in the Established state and immediately restarts the 
Inactivity/Watchdog timer. This value is invalid for Explicit Messaging Connections. 


3 Deferred Delete. The Connection transitions to the Deferred state if any child connection 
instances are in the Established state. If no child connection instances are in the 
Established state the connection is deleted. This value is only used on DeviceNet and is 
invalid for I/O Messaging Connections. 


4-FF | Reserved by CIP 
UINT produced_connection_path_length 


Specifies the number of bytes of information within the produced_connection_path attribute. 
This is automatically initialized when the produced_connection_path attribute is configured. 
This attribute defaults to the value zero (0). 
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EPATH produced_connection_path 


The produced_connection_path attribute is made up of a byte stream which defines the 
Application Object(s) whose data is to be produced by this Connection Object. The format of 
this byte stream is specified in Appendix C, Abstract Syntax Encoding for Segment 

Types. This attribute defaults to being empty upon instantiation of the Connection. It remains 
empty within Explicit Messaging Connections and within Connection Objects that do not 
produce. 


UINT consumed_connection_path_length 


Specifies the number of bytes of information within the consumed_connection_path attribute. 
This is automatically initialized when the consumed_connection_path attribute is configured. 
This attribute defaults to the value zero (0). 


EPATH consumed_connection_path 


The consumed_connection_path attribute is made up of a byte stream which defines the 
Application Object(s) that are to receive the data consumed by this Connection Object. The 
format of this byte stream is specified in Appendix C, Abstract Syntax Encoding for 
Segment Types. This attribute defaults to being empty upon instantiation of the Connection. It 
remains empty within Explicit Messaging Connections and within Connection Objects that do 
not consume. 


UINT production_inhibit_time 


This attribute is used to configure the minimum delay time between new data production. This 
is required for all I/O Client connections, except those with a production trigger of Cyclic. The 
Set_Attribute_Single service must be supported when this attribute is implemented. A value of 
zero (the default value for this attribute) indicates no inhibit time. 


The resolution of this attribute is in milliseconds. A request to configure this attribute may 
result in the specification of time value that a product cannot meet. In addition to performing 
product specific range checking when a request to modify this attribute is received, the 
following steps are performed: 


e If the specified value is not equal to an increment of the available clock resolution, then the value is 
rounded up to the next serviceable value. For example: a Set_Attribute Single request is received 
specifying the value 5 for the production_inhibit_time attribute and the product provides a 10 
millisecond resolution on times. In this case the product would load the value 10 into the 
production_inhibit_time attribute. 


e = The value that is actually loaded into the production_inhibit_time attribute is reported in the 
Service Data Field of a Set_Attribute_Single response message associated with a request to modify 
this attribute. 


e Ifthe requested value is equal to an increment of the clock resolution, then the requested value is 
loaded into the production_inhibit_time and reported in the response. For example: the value 100 
is requested and the clock resolution is 10 milliseconds. 


The production_inhibit_time value is loaded in the Production Inhibit Timer each time new 
data production occurs. 
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When a Connection Object is in the Established state, any modifications to the 
production_inhibit_time attribute have no effect on a currently running Production Inhibit 
Timer. The new production_inhibit_time value is loaded into the Production Inhibit Timer on 
the following new data production. 


When the apply_attributes service is received, the production_inhibit_time must beverified 
against the expected_packet_rate attribute. If the expected_packet_rate value is greater than 
zero, but less than the production_inhibit_time value, then an error shall be returned. In this 
case, where two attribute values conflict use the production_inhibit_time attribute ID as the 
additional error code returned in the error response. 


Connection Timing 
Three types of timers are involved in a connection: 


e Transmission Trigger Timer 
e = Inactivity/Watchdog Timer 
e Production Inhibit Timer 


The first two timers are initialized based on the value in the expected_packet_rate attribute. 


Important: For Explicit Messaging, the Application is responsible for providing response 
timeout facilities. The amount of time a Client waits for a Server to respond to a request 
depends on the application and, possibly, on the service. Due to Media Access mechanisms 
used for accessing the subnet, an implementation should wait until an Explicit Request 
Message is transmitted before activating any response related timers. 


Transmission Trigger Timer 

This timer is required to be managed by the application within the Client end-point of a 
Connection. Expiration of this timer is an indication that the associated Connection Object may 
need to be told to transmit a message. If a production has not occurred since the timer was 
activated, then the Connection Object should be told to produce to avoid an 
Inactivity/Watchdog timeout at the Server end-point(s). 


The tasks listed below are performed by a Connection immediately upon producing a message 


e The current value of the Transmission Trigger Timer is restored to its initial value and 
the timer is stopped. 
e A new Transmission Trigger Timer is activated. 
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3-4.4.2 


Release 1.0 


Figure 3-4.24.Transmission Trigger Timer 
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As illustrated in Figure 3-4.24, when the Transmission Trigger Timer expires, it is immediately 
re-started. This timer is activated when the Connection transitions to the Established state. 


Important: The Transmit Trigger Timer is initialized with the value in the 
expected_packet_rate attribute. If the expected_packet_rate attribute contains the value zero 
(0), then the Transmission Trigger Timer is not activated and/or used by the Client end-point. 


Important: Server end-points do not activate this timer. 


Inactivity/Watchdog Timer 


This timer is required to be managed by any consuming Connection Object. Consuming 
Connection Objects include: 
e Client end-point Connection Objects whose transportClass_trigger attribute indicates 
either Transport Class 2 or 3 
e All Server end-point Connection Objects 


This timer is activated when the Connection transitions to the Established state. The tasks 
listed below are performed by a Connection immediately upon detecting that a valid message 
has been consumed: 
e The current value for the Inactivity/Watchdog Timer is restored to its initial value and 
the timer is stopped. 
e A new Inactivity/Watchdog Timer is activated. 


The bullet items above indicate that the new Inactivity/Watchdog Timer is activated before the 
received message is processed. 


Expiration of this timer is an indication that the Connection Object has timed out while waiting 
to consume. The Connection Object performs the following steps when the 
Inactivity/Watchdog timer expires: 

e issues an indication of this event to the application 

e performs the action indicated by the watchdog_timeout_action attribute 
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Two different values are used for the Inactivity/Watchdog Timer, based on whether or not the 
Connection Object has consumed a message: 


1. The initial value loaded into the Inactivity/Watchdog Timer is either 10,000 milliseconds (10 
seconds) or the expected_packet_rate multiplied by 4, depending on which value is numerically 
greater’. If the expected_packet_rate attribute multiplied by 4 is greater than 10,000, then the 
expected_packet_rate multiplied by 4 is used. Otherwise, 10,000 (10 seconds) is used. This is 
referred to as the pre-consumption timeout value. This value is used because a Connection may 
transition to the Established state before all end-points are fully configured. For example: 


The tool configures the server endpoint of a connection within device 
B. The tool send an Apply Request which causes the transition to the 
Established state and activates the Inactivity/Watchdog Timer. 


Ke) 
Connection 
Obiect 


Device B 


The tool configures the client endpoint of the connection. While 


performing this configuration, the Server endpoint times out due to the 
fact that a low expected_packet_rate was specified. 


Vo 
Connection 
Obiect 


Device A 


If the expected_packet_rate attribute contains the value zero (0), then the Inactivity/Watchdog Timer is 
not activated and/or used by the Connection Object. A Connection Object whose expected_packet_rate 
attribute is zero (0) will never experience an Inactivity/Watchdog timeout. 
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This rule takes into consideration that the application-to-application connection is not really 
established until the associated information exchange is performed for the first time. 


2. All subsequent activations of the Inactivity/Watchdog Timer use the expected_packet_rate 
multiplied by 4 (expected_packet_rate << 2) as the number of milliseconds to load into the 


Inactivity/Watchdog Timer ~. 


3-4.4.3 Production Inhibit Timer 


This timer is required to be managed by the Connection Object within the Client end-point of 
an I/O Connection when the production_inhibit_time attribute value is non-zero. This timer 
is started when data is produced by the Connection Object. The Connection Object may not 
produce new data if this timer is running. A retry may, however, be sent to the Link Producer. 
Expiration of this timer allows the Connection Object to send new data. 


SME EOE oe terete ter cge Sree isha 
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Object . \ 


©) The connection may be ‘Ss < -* 
told to produce a retry “~+..-- i 
This will be the data previously sent 
in event 1. 


Important: The Production Inhibit Timer is initialized with the value in the 
production_inhibit_time attribute. If the production_inhibit_time attribute contains the 
value zero (0), then the Production Inhibit Timer is not activated and/or used by the Client end- 
point. 


Important: Server end-points do not activate this timer. 


If the expected_packet_rate attribute contains the value zero (0), then the Inactivity/Watchdog Timer is 
not activated and/or used by the Connection Object. A Connection Object whose expected_packet_rate 
attribute is zero (0) will never experience an Inactivity/Watchdog timeout. 
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3-4.5 Connection Object Instance Services 


The Connection Object Instance supports the following CIP Common services: 


Table 3-4.24. Connection Object Instance Services 


Service Need In Service Name Service Description 
Code _ | Implementation 
OE nex Used to read a Connection Object attribute. 
Single 


10hex Optional Set_Attribute_ | Used to modify a Connection Object attribute. The Connection 
Single Object returns information in the Service Data Field of a 
Set_Attribute_Single Response when the expected_packet_rate 


attribute is modified as indicated in Table 3.21 


OS hex Optional Reset Used to reset the Inactivity/Watchdog Timer associated with a 
Connection Object. When a Connection in the Timed Out or 
Deferred Delete state receives a Reset request it also transitions 
back to the Established state. 


O9 nex Optional Used to delete a Connection Object and to release all associated 
resources. 


ODhex Optional Apply_Attributes | Used to deliver the Connection Object to the application which 
performs the set of tasks necessary to create the specified 
connection. A Connection Instance returns the 
produced_connection_id and consumed_connection_id 
attributes within the Service Data field of an Apply Attributes 
Response Message as indicated in Table 3.20. The 
Apply_Attributes service effectively states that the initial 
configuration of the Connection Object is complete and it is now 


time to ”activate” that configuration. 


The following information is specified by a Connection Object Instance within the Service 
Data Field of a successful Apply Attributes response . 


Table 3-4.25. Service Data For Connection Object Apply Attributes Response 


Name Data Type Description of Parameter 


Produced Connection ID UINT Contains the value within the Connection Instance’s 
produced_connection_id attribute 


Consumed Connection ID UINT Contains the value within the Connection Instance’s 
consumed_connection_id attribute 
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The figure below illustrates the Apply_Attributes service sent to a Connection Object Instance. 


Assume an Explicit Messaging Connection was established across Group 2 and the Message Body Format was defined by 
the Server as DeviceNet (16/16). 


_Client___ _—Server___ 
MAC ID=0A | Group 2 Message MAC ID =2 


Destination MAC ID = 2 
yj Assume the Server allocated Group 2 Message ID | to the Client. 


Frag = 0, Transaction ID = 0, Source MAC ID = 0A (Destination in Identifier) 
Service = Apply Attributes Request 


Class ID = 5 (Connection Object Class) 
| [ Instance ID = 02 


Identifier = 10 000010 001, Data=0A_ 0D _ 0500 0200 » 


-— Group 2 Message 
Source MAC ID = 2 
Assume the Server allocated Group 2 Message ID value 4 for itself 
Frag = 0, Transaction ID = 0, Destination MAC ID = 0A (Source in Identifier) 
; Service = Apply Attributes Response (Success) 


Connection Instance #2's produced_connection_id attribute value 
j Connection Instance #2's consumed_connection_id attribute value 


Identifier = 10 000010 100, Data=0A 8D 4200 0500 


The following information is specified by a Connection Object Instance within the Service 
Data Field of a successful Set_Attribute_Single response associated with the modification of 


the expected_packet_rate attribute. 
Table 3-4.26. Service Data For Connection Object 


Set_Attribute_Single[expected_packet_rate] Response 


Name Data Type Description of Parameter 


Contains the actual value within the Connection 


Expected Packet Rate 
Instance’s expected_packet_rate attribute. 


The illustration below depicts a Client requesting that the expected_packet_rate be set to 5 
milliseconds. The Server returning a successful response stating that the attribute was actually 


set to 10 milliseconds. 
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Assumes an Explicit Messaging Connection was established across Group 2 and the Message Body Format was defined by 
the Server as DeviceNet (8/8). Assume also that the expected_packet_rate attribute of Connection Instance #1 is requested 
to be set to 5 milliseconds but the product supports a 10 millisecond resolution. 


Client Server 


MACID=0A [f= . Groupe Messeee MAC ID=2 
Destination MAC ID = 2 


Assume the Server allocated Group 2 Message ID 1 to the Client. 


Frag = 0, Transaction ID = 0, Source MAC ID = 0A (Destination in Identifier) 
Service = Set Attribute Single 


Class 5 (Connection Class) 
Instance ID = 02 
| Attribute ID = 09 (expected_packet_rate) 
I Service Data (attribute value = 5 milliseconds) 
Identifier = 10 000010 001, Data=0A 10 05 0200 09 0500 > 


Group 2 Message 
Source MAC ID = 2 


Assume the Server allocated Group 2 Message ID value 4 for itself 


Frag = 0, Transaction ID = 0, Destination MAC ID = 0A (Source in Identifier) 
[Service = Set Attribute Single Response (Success) 


| Service Data (attribute value = 10 milliseconds) 


< Identifier = 10 000010 100, Data=0A_90 0A00 


The Connection Object does not return any information in the Service Data Field of a 
Set Attribute Single response directed towards any other of its attributes. 


The Connection Object also supports the following internal services: 


e Send_Message - Used internally to trigger the transmission of a message. This results 
in the invocation of the associated Link Producer’s Send service. If the message needs 
to be transmitted in a fragmented fashion, this service breaks up the message into 
multiple fragments and invokes the associated Link Producer’s Send service multiple 
times. 

e Receive_Data - Used internally to deliver a received frame to the Connection Object. 
This service is invoked internally by a Link Consumer. The Connection Object is 
responsible for determining whether or not it must reassemble a series of data fragments 
into a complete message before processing the message. 


3-4.6 Connection Instance Behavior 


3-4.6.1 I/O Connection Instance Behavior 


Figure 3-4.27 provides a general overview of the behavior associated with an I/O Connection 
Object (instance_type attribute = I/O). 
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Figure 3-4.27. I/O Connection Object State Transition Diagram 
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A Connection Object issues the internal indications described in Figure 3-4.28 to an 
application within a product. The purpose of this specification is to describe externally 
visible behaviors; rules pertinent to specific internal indications are not defined. 


Delete 


Figure 3-4.28. Internal Indications Issued by a Connection Object (Conceptual) 
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Important: Table 3-4.29 provides a detailed State Event Matrix for an I/O Connection Object 
and implementations should be based on this information. This State Event Matrix does not 
dictate rules with regards to product specific, internal logic. Any attempt to access the 
Connection Class or a Connection Object Instance may need to pass through product specific 
verification. This may result in an error scenario that is not indicated by the SEM in Table 3- 
4.29. This may also result in additional, product specific indications delivered from a 
Connection Object to the application and/or a specific Application Object. The point to 
remember is that the Connection Object must exhibit the externally visible behavior specified 
by the SEM and the attribute definitions (section 3-4.3). 
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Table 3-4.29. I/O Connection State Event Matrix 
1/O Connection Object State 


Non-Existent Configuring Waiting for Established Timed Out 
Connection ID 


Event 


Connection Class 
receives a Create 
Request 


Connection Class 
receives a Delete 
Request 


Set_Attribute_Single 


Get_Attribute_Single 
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Class Not applicable 
instantiates a 
Connection 
Object. Set 
instance_type 
to I/O. Set all 
other 
attributes to 
default values. 
Transition to 
Configuring 
Error: Object 
does not exist 
(General Error 
Code 16p¢,) 


Release all associated 
resources. Transition to 
Non-existent 


Validate/service the 
request based on internal 
logic and per the Access 
Rules presented in section 
3-4.7. Return response. 


Error: Object 
does not exist 
(General Error 
Code 16.) 


Validate/service the 
request based on internal 
logic and per the Access 
Rules presented in section 
3-4.7. Return response. 


Error: Object 
does not exist 
(General Error 
Code 16p¢x) 


Not applicable 


Release all associated 
resources. Transition to 
Non-existent. 


If request to modify 
produced or 
consumed_connection_id 
then validate the value and 
service the request. Return 
appropriate response. If 
this is a request to access 
an attribute other than the 
produced or 

consumed _connection_id, 
then return an Error 
Response whose General 
Error Code is set to OCphey 


(The object can not 
perform the requested 
service in its current 
mode/state) 
Validate/service the 
request based on internal 
logic and per the Access 
Rules presented in section 
3-4.7. Return response. 


Not applicable 


Release all associated 
resources. Transition to 
Non-existent. 


Validate/service the request 
based on internal logic and 
per the Access Rules 
presented in section 3-4.7. 


Return appropriate response. 


Validate/service the request 
based on internal logic and 
per the Access Rules 
presented in section 3-4.7. 
Return response. 
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Not applicable 


Release all 
associated 
resources. 
Transition to 
Non-existent. 
Validate/service 
the request based 
on internal logic 
and per the 
Access Rules 
presented in 
section 3-4.7. 
Return 
appropriate 
response. 


Validate/service 
the request based 
on internal logic 
and per the 
Access Rules 
presented in 
section 3-4.7. 
Return response. 
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Event 
Reset 


Apply_ Attributes 


Release 1.0 


Non-Existent 


Error: Object 
does not exist 
(General Error 
Code 16p¢x) 


Error: Object 
does not exist 
(General Error 
Code 16p¢x) 


Configuring 


Error: The object cannot 
perform the requested 
service in its current 
mode/state. (General 
Error Code value =) 


Deliver Connection 
Object to the application 
which validates the 
attribute information. If 
either of the 
connection_id attributes 
(produced or consumed) 
needs to be configured 
and cannot be generated 
by this module, then 
perform all the other steps 
necessary to configure the 
connection, return a 
Successful Response and 
transition to the Waiting 
For Connection ID state. 
The inability to generate a 
produced or consumed 
connection ID value IS 
NOT reported as an error. 
If all attributes are validly 
configured, then perform 
all the steps necessary to 
satisfy this connection, 
start all required timers, 
and transition to the 
Established state. If an 
error is detected, then an 
Error Response is 
returned and the 
Connection remains in 


the Configuring state! 


and, if a Client 
Connection with a 
production trigger value 
of 0 or 1 (Cyclic or 
Change of State), produce 
initial data. 
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1/O Connection Object State 


Waiting for 
Connection ID 


Error: The object cannot 
perform the requested 
service in its current 
mode/state. (General Error 
Code value = 0C},.,) 


If either of the 
connection_id attributes 
(produced or consumed) 
still needs to be configured 
and cannot be generated by 
this module, then return a 
Successful Response and 
remain in the Waiting For 
Connection ID state. The 
inability to generate a 
produced or consumed 
connection ID value IS 
NOT reported as an error. 
If the produced and/or 
consumed_connection_id 
attributes are now validly 
configured, then transition 
to the Established state 
and return a Successful 


Response! and, if a Client 
Connection with a 
production trigger value of 
0 or | (Cyclic or Change of 
State), produce initial data. 


Established Timed Out 


Cancel the current 
Inactivity/Watchdog Timer. 


Using the value 
in the 


Using the value in the expected_packet 
expected_packet_rate _rate attribute, 
attribute, re-start the start the 
Inactivity/Watchdog Timer. Inactivity/Watch 


dog timer and 
transition back 
to the 


A success response is 
returned even if an 
Inactivity/Watchdog Timer is 


not utilized by the Connection | Established 
Object (Client Transport state . 

Class 0, If the 
expected_packet_rate = expected_packet 


00Ch ex): _rate attribute 
has been set to 
zero (0) while the 
Connection was 
in the Timed 
Out state, then 
just transition 
back to 
Established 
without 
activating an 
Inactivity/Watch 
dog Timer. 
Error: The object 
cannot perform 
the requested 
service in its 


All modifications take place 
immediately once the 
Connection has transitioned 
to the Established state. 


Return Error: The object current 

cannot perform the requested | mode/state. 
service in its current (General Error 
mode/state. (General Error Code value = 
Code value = 0C},,,) OChex) 
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1/O Connection Object State 


Non-Existent Configuring Waiting for Established Timed Out 
Event Connection ID 


Receive _Data Not applicable | Discard the message Discard the message Discard the 
message 


If a complete, valid22 
message has been received, 
reset the Inactivity/Watchdog 


Timer? and deliver the I/O 
Message to the Application. 
A Connection Object must 
exhibit the externally visible 
behavior associated with the 
current state of its attributes 
(see section 3-4.3). If this is a 
fragmented portion of an I/O 
Message, process as specified 
by subnet. 
Send_Message Not applicable | Return internal error - do | Return internal error - do Transmit the complete I/O Return internal 
not send the message not send the message Message or fragment as error - do not 
required by the subnet. If this | send the message 
is a Client Connection and the 
expected_packet_rate 
attribute is non-zero, restart 
the Transmission Trigger 
Timer. 
Inactivity/Watchdog | Not applicable | Not applicable Not applicable Examine the Not applicable 
Timer expires watchdog _timeout_action 
attribute of the Connection 
and perform the indicated 
action. If the 
watchdog _timeout_action 
attribute indicates that the 


Connection is to remain in the 
Established state (Auto 
Reset), then immediately 
re-start the 
Inactivity/Watchdog Timer. 


! ifthe configuration indicates that a Message ID needs to be allocated and an available Message ID does not exist in the specified 
Message Group, then an Error Response whose General Error Code indicates Resource Unavailable (02p¢x) is returned. Ifa 


Connection Object attribute value passed the range check when it was initially configured but the attribute value conflicts with 
another piece of information in the node when the Apply request is processed, then an Error Response is returned whose General 
Error Code is set to Invalid Attribute Value (O9,¢ex) and whose Additional Code is set to the Attribute ID of the offending 


Connection Object Attribute ID. 


2 The Connection Object verifies that the length of the received I/O Message is less than or equal to the 
consumed_connection_size attribute prior to processing the message. If the length of the received message is less than or equal 
to the consumed_connection_size attribute, then the I/O Connection Object resets the Inactivity/Watchdog Timer, exhibits the 
externally visible behavior indicated by its attribute settings, and delivers the message to the Application. If the length of the 
received message is greater than the consumed_connection_size attribute, then the I/O Connection Object immediately discards 
the message and discontinues any subsequent processing. This is the only message content validation performed by an I/O 
Connection Object. Subsequent validation must be performed by the Application. 


3 Ifa fragmented message is being received, then the Inactivity/Watchdog Timer is not reset until the entire message has been 
validly received. 


Important: The Receive _Data event is only delivered to an I/O Connection when a message 
whose CAN Identifier Field matches the consumed_connection_id attribute is received. Ifa 
message is received whose CAN Identifier Field does not match any Established Connection 
Object’s consumed _connection_id attribute, then the message is discarded. 


If an implementation detects that it does not support an Explicit Messaging Service indicated in 


Table 3.22 , then an Error Response specifying Service Not Supported (General Error Code 08) 
is returned. 
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CIP Bridged Connection Instance Behavior 


Figure 3-4.29 provides a general overview of the behavior associated with a CIP Bridged 
Connection Object (instance_type attribute = CIP Bridged). CIP Bridged connections are 
used to make connections offlink. Both I/O and Explicit Messaging can be accomplished using 
this connection type. The Connection Manager Object definition provides more details these 
types of connections. 


Figure 3-4.29. C 


IP Bridged Connection Object State Transition Diagram 
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Table 3-4.30 provides a detailed State Event Matrix for a CIP Bridged Connection Object. 


Table 3-4.30. CIP Bridged Connection State Event Matrix 


CIP Bridged Connection Object State 


Event Non-Existent Configuring Established Closing 
Connection Manager | Connection Class Not applicable Not applicable Not applicable 
receives a Forward instantiates a 
Open Request Connection Object. Set 

instance_type to CIP 
Bridged. Set attributes 
to value delivered by 
Forward Open service 
or default for CIP 
Bridged connections. 
Transition to 
Configuring. 
Connection Manager | Not applicable Transition to Not applicable Not applicable 
receives notification Established 
that connection 
establishment is 
complete to target 
Connection Manager | Not applicable Ignore event Transition to Closing Ignore event 
receives a Forward 
Close Request 
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Event 


CIP Bridged Connection Object State 


Non-Existent 


Configuring 


Established 


Closing 


Connection Manager 
receives a Forward 


Close Response 


Not applicable 


Release all resources 
and transition to 
Non-Existent 


Release all resources 
and transition to Non- 
Existent 


Release all resources 
and transition to Non- 
Existent 


Delete 


Error: Object does not 
exist (General Error 
Code 1 6hex) 


Release all resources 
and transition to 
Non-Existent 


Release all resources 
and transition to Non- 
Existent 


Release all resources 
and transition to Non- 
Existent 


Get_Attribute_Single 


Error: Object does not 
exist (General Error 
Code 16hex) 


Set_Attribute_Single 


Error: Object does not 
exist (General Error 
Code 16hex) 


Validate/service the 
request based on 
internal logic and per 
the Access Rules 
presented in section 
3-4.7. Return 
appropriate response. 


Validate/service the 
request based on 
internal logic and per 
the Access Rules 
presented in section 3- 
4.7. Return 
appropriate response. 


Validate/service the 
request based on 
internal logic and per 
the Access Rules 
presented in section 3- 
4.7. Return 
appropriate response. 


Reset 


Error: Object does not 
exist (General Error 
Code 16hex) 


Error: Service Not 
Supported (General 
Error Code O08hex) 


Error: Service Not 
Supported (General 
Error Code 08hex) 


Error: Service Not 
Supported (General 
Error Code O8hex) 


Apply_ Attributes 


Error: Object does not 
exist (General Error 


Error: Service Not 
Supported (General 


Error: Service Not 
Supported (General 


Error: Service Not 
Supported (General 


Code 16hex) Error Code O8hex) Error Code 08hex) Error Code O8hex) 
Receive _Data Not applicable Ignore event Invoke send service of | Ignore event 
connection object on 
destination port, 
passing the received 
data. 
Send_Message Not applicable Ignore event Send data on subnet. Ignore event 
Inactivity/Watchdog Not applicable Not applicable Release all resources Release all resources 


Timer expires 


and transition to Non- 
Existent 


and transition to Non- 
Existent 


Explicit Messaging Connection Instance Behavior 


Figure 3-4.31 provides a general overview of the behavior associated with an Explicit 
Messaging Connection Object (instance_type attribute = Explicit Messaging). 
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Figure 3-4.31. Explicit Messaging Connection Object State Transition Diagram 
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state 


Open Explicit Messaging Connection 
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Inactivity/Watchdog Timeout & 
watchdog timeout_action = 
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Table 3-4.32 provides a detailed State Event Matrix for an Explicit Messaging Connection 
Object. Implementations should be based on the information in Table 3-4.32. 


Table 3-4.32. Explicit Messaging Connection State Event Matrix 


Explicit Messaging Connection Object State 


Event Established Deferred Delete 


UCMM receives an If possible, Class instantiates | Not applicable Not applicable 
Open Explicit Connection Object. Set 

Messaging Connection | instance_type attribute to 

Request/Response and 
invokes the Create 
service of the 
Connection Class 


Explicit Messaging! . Other 
attributes are automatically 
configured using the 
information in the Open 
Explicit Messaging Connection 
Request/Response. Transition 
to Established. If request 
received, Transmit Open 
Explicit Messaging Connection 


Response. 
UCMM receives a Close | Error: Object does not exist Release all associated resources. Release all associated 
Request and invokes the | (General Error Code 16),,,) Transition to Non-existent. resources. Transition to 


Delete service of the Non-existent. 


Connection Class 


Connection Class Error: Object does not exist Release all associated resources. Release all associated 

receives a Delete (General Error Code 16),,,) Transition to Non-existent. resources. Transition to 

Request Non-existent. 

Set_Attribute_ Single Error: Object does not exist Validate/service the request based | Validate/service the request 

(General Error Code 16p¢,) on internal logic and per the Access | based on internal logic and per 
Rules presented in section 3-4.7. the Access Rules presented in 
Return appropriate response. section 3-4.7. Return 
appropriate response. 
Get_Attribute_Single Error: Object does not exist Validate/service the request based | Validate/service the request 


(General Error Code 16),.,,) on internal logic and per the Access | based on internal logic and per 
Rules presented in section 3-4.7. the Access Rules presented in 
Return appropriate response. section 3-4.7. Return 

appropriate response. 
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Event 


Reset 


Apply_Attributes 


Receive Data 


Send_Message 


Inactivity/Watchdog 
Timer 
expires 


Child connection 
instance Deleted or 
Transitions to Timed 
Out 
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Explicit Messaging Connection Object State 


Cancel the current 
Inactivity/Watchdog Timer. Using 
the value in the 
expected_packet_rate attribute, 
re-start the Inactivity/Watchdog 
Timer. 

Error: The object cannot perform 
the requested service in its current 
mode/state. (General Error Code 
value = 0Chex) 


Error: Object does not exist 
(General Error Code 16),.,) 


Error: Object does not exist 
(General Error Code 16),,,) 


Not applicable If a valid message or message 
fragment has been received, then 


reset the Inactivity/Watchdog 


Timer. Hither process/store the 
fragment or handle the Explicit 
Message. 


Not applicable Examine the length of the message 
to transmit and, if necessary, 
perform a fragmented series of 
transmissions. Otherwise, transmit 


the complete Explicit Message. 


Not applicable If the watchdog_timeout_action 
attribute is set to Auto Delete or is 
set to Deferred Delete and no child 
connection instances are in the 
Established state release all 
associated resources and Transition 
to Non-existent . If the 
watchdog_timeout_action 
attribute is set to Deferred Delete 
and at least one child connection 
instance is in the Established state 
transition to Deferred. Delete 


Ignore event 


Not applicable 


Deferred Delete 


Using the value in the 
expected_packet_rate 
attribute, re-start the 
Inactivity/Watchdog Timer_and 
transition back to the 
Established state. 

Error: The object cannot 
perform the requested service 
in its current mode/state. 
(General Error Code value = 


0Chex) 


If a valid message or message 
fragment has been received, 
then restart the 


Inactivity/Watchdog Timer 
and transition back to the 
Established state. Either 
process/store the fragment or 
handle the Explicit Message. 
Examine the length of the 
message to transmit and, if 
necessary, perform a 
fragmented series of 
transmissions. Otherwise, 
transmit the complete Explicit 
Message. 

Not applicable. 


If no other child connection 
instances are in the 
Established state release all 
associated resources and 
transition to Non-existent. 


lif the configuration indicates that a connection resource needs to be allocated and an available resource does not 
exist, then an Error Response whose General Error Code indicates Resource Unavailable (02x) is returned. 


20n DeviceNet, the MAC ID field within the Message Header of all Explicit Messages and/or Message Fragments 
is examined. If the Destination MAC ID is specified in the Connection ID (CAN Identifier Field), then the Source 
MAC ID of the other end-point must be specified in the Message Header. If the Source MAC ID is specified in the 
Connection ID, then the receiving module’s MAC ID must be specified in the Message Header. If either of these 
checks fail, then the Inactivity/Watchdog Timer IS NOT reset and the message/message fragment is discarded. 


Important: The Receive _Data event is only delivered to an Explicit Messaging Connection 
when a message whose Connection ID matches the consumed_connection_id attribute is 
received. If a message is received whose connection id does not match any Established 
Connection Object’s consumed _connection_id attribute, then the message is discarded. 


Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1; CIP Common Specification 


3-4.7 


Release 1.0 


Chapter 3: Communication Object Classes 


If an implementation detects that it does not support an Explicit Messaging Service indicated in 
Table 3-4.32, then an Error Response specifying Service Not Supported (General Error Code 
08) is returned. 


Connection Object Attribute Access Rules 


During the configuration of a Connection instance using the Set_Attribute service, a module 
must perform value checks of each separate attribute when is modified. If an error is detected, 
then an Error Response is returned. The discovery of an error DOES NOT cause the deletion 
of the Connection instance. 


Important: If the produced_connection_id and/or consumed_connection_id attributes contain 
a non-default value upon reception of the Apply Request, then the related portion of the 
initial_ comm_characteristics attribute is ignored and the ID value is validated and used. 


The following series of tables indicates when an attribute can be read or written via a Get 
and/or Set operation based on the Connection’s state and instance_type. 


Important: If a request to Get/Set a supported attribute is received but the current state and/or 
instance_type of Connection dictates that the requested access is invalid, then the returned error 
status indicates: The object cannot perform the requested service in its current mode/state 
(General Error Code value = 0C;,, - see Appendix B for more information on error codes). 


Table 3-4.33. 1/0 Connection Object Attribute Access 


I/O Connection State 


Waiting for 
Non-Existent | Configuring Connection ID Established | Timed Out 


Attribute 


State 

instance_type 

transport Class_trigger 
produced_connection_id 
consumed_connection_id 
initial comm_characteristics 
produced_connection_size 
consumed_connection_size 


expected |_packet_rate! 


watchdog timeout_action 


produced_connection_ 
path_length 


produced_connection_path 


consumed_connection_ 
path_length 


consumed_connection_path 


production_inhibit_time 
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Not available | Get Only Get Only Get Only 
Not available |Get Only Get Only Get Only 
Not available Get Only Get Only Get Only 


Get/Set Get/Set 


Not available Get Only Get/Set 


Not available | Get Only Get Only Get Only Get Only 


Not available Get Only Get Only Get Only 


Not available | Get Only Get Only Get Only Get Only 


Not available Get Only Get Only Get Only 
Not available | Get/Set Get Only Get/Set 


3-45 


Chapter 3: Communication Object Classes Volume 1: CIP Common Specification 


I/O Connection State 


Waiting for 
Non-Existent | Configuring Connection ID Established | Timed Out 


1 When a Connection Object is in the Established state, any modifications to the expected_packet_rate attribute 
have immediate effect on the Inactivity/Watchdog Timer. The following steps are performed by a Connection 
Object in the Established state when a request is received to modify the expected_packet_rate attribute: 


Attribute 


- the current Inactivity/Watchdog Timer is canceled 


- anew Inactivity/Watchdog Timer is activated based on the new value in the expected_packet_rate attribute. 


Table 3-4.34. CIP Bridged Connection Object Attribute Access 


Default CIP Bridged Connection State 

1 

Attribute Value Non-Existent Configuring Established Closing 

state 1 Not Available Get Only Get Only Get Only 

instance_type 2 Not Available Get Only Get Only Get Only 

transportClass_trigger From Not Available Get Only Get Only Get Only 
service 

produced_connection_id From Not Available Get Only Get Only Get Only 
service 

consumed_connection_id From Not Available Get Only Get Only Get Only 
service 

initial comm_characteristics From Not Available Get Only Get Only Get Only 
service 

produced_connection_size From Not Available Get Only Get Only Get Only 
service 

consumed_connection_size From Not Available Get Only Get Only Get Only 
service 

expected_packet_rate From Not Available Get Only Get Only Get Only 
service 

watchdog timeout_action 1 Not Available Get Only Get Only Get Only 

produced_connection_path_ From Not Available Get Only Get Only Get Only 
length service 

produced_connection_path From Not Available Get Only Get Only Get Only 
service 

consumed_connection_path_ From Not Available Get Only Get Only Get Only 
length service 

consumed_connection_path From Not Available Get Only Get Only Get Only 
service 

production_inhibit_time From Not Available Get Only Get Only Get Only 
service 


'The default value is either the value indicated or is set based on one of the parameters of the Forward Open service 
received by the Connection Manager object. 
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Table 3-4.35. 


Attribute 
State 
instance_type 
transportClass_trigger 
produced_connection_id 
consumed_connection_id 
initial_comm_characteristics 
produced_connection_size 
consumed_connection_size 


expected |_packet_rate! 


watchdog _timeout_action 


produced_connection_ 
path_length 


produced_connection_path 


consumed_connection_ 
path_length 


consumed_connection_path 


production_inhibit_time 


Non 
ot available 
ot available 
ot available 
ot available 
ot available 
ot available 
ot available 
ot available 


ot available 


ot available 


Not available 


Not available 


Not available 


Not available 


Not available 


-Existent 


Explicit Messaging Connection Object Attribute Access 


Explicit Messaging Connection State 


Established/Deferred Delete 
Get Only 
Get Only 
Get Only 
Get Only 
Get Only 
Get Only 
Get Only 
Get Only 


Get/Set! 
Get/Set 
Get Only 


Get Only 
Get Only 


Get Only 


Get Only 


Chapter 3: Communication Object Classes 


1 When a Connection Object is in the Established state, any modifications to the expected_packet_rate attribute 

have immediate effect on the Inactivity/Watchdog Timer. The following steps are performed by a Connection 

Object in the Established state when a request is received to modify the expected_packet_rate attribute: 
- the current Inactivity/Watchdog Timer is canceled 
- anew Inactivity/Watchdog Timer is activated based on the new value in the expected_packet_rate attribute. 
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3-4.8 Dynamic Management Of Message IDs 


Dynamically establishing both I/O and Explicit Messaging Connections requires the end-points 
go through an internal Message ID allocation process. For example: 


1. Current state of the "Group 1 Message ID Allocation Table" 


Message ID 0 Allocated 
Message ID 1 Allocated 


ae Message ID 2 Available 
/ 
ra Message ID 3 Available 


U ae Br. e Oaeeaeaeete 


/ 
! Message ID OF | Available 


2. An I/O Connection is created & configured which requests that a new production take place 
across Group 1 


0 
Connection 


"produce across 


I 
I 
t 
! 
! 
I 
] 
I 
1 
i) 
\ 
1 
i] 
1 Group 1" 


Message ID 0 Allocated 
Message ID 1 Allocated 


Message ID 2 Allocated 
Message ID 3 Available 


Message ID OF | Available 
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Additionally, devices which implement fully dynamic Connection creation/deletion capabilities 
will also have to implement logic which marks a previously allocated Message ID as available 
when that Message ID is no longer in use. For example: 


1. Current state of the"Group 1 Message ID Allocation Table" 


Message ID 0 
Message ID 1 


ze Message ID 2 
7 
ra Message ID 3 


/ 
i Message ID OF | Available 


2. The I/O Connection is deleted 


i es 


‘ 3. Group 1 Message ID value 2 is now available again. 


Message ID 0 


Message ID OF | Available 
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The act of re-using a previously allocated Message ID for a different purpose gives rise to 
many issues. For example: 


1. Assume the following configuration where the Producing I/O Connection in Device #1 is 
Analog Value identified by Identifier Field value 01hex. The Consuming I/O Connection is 
Identifier 01hex and when a consumption occurs it hands the data up to Application Object ‘B’. 
Application Object ‘B’ assumes it is receiving an Analog Value and processes accordingly. 


Application 
Object 
man 


A 32 bit Analog Value 


. Identifier = 01hex, : A 32 bit Analog 
Producing Data = 4 bytes of I/O Data or aune Value 
ke) 
Connection Connection 


Device #1 Device #2 


2. Assume that the Producing I/O Connection is Deleted and the associated Message ID is marked as 
available. Assume a new Producing I/O Connection is created and configured such that it re-uses this 
Message ID and generates the Identifier 01hex which is now associated with a 32 bit Discrete Image. 
Device #3 is configured to consume this message as illustrated. 


A 32 bit Discrete 
Image 


Identifier = 01hex, A 32 bit Discrete 


end Data = 4 bytes of I/O Data conaning Image 


Connection Connection 


Device #1 Device #3 
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3. There is a problem in that Application Object B within Device #2 processes a received I/O Message as a 
32 bit Analog Value.The associated Consuming I/O Connection within Device #2 is still active and 
screening for Message ID 01hex. Application Object B in Device #2 will now receive what it believes to 


be an Analog Value but it is actually a 32 bit Discrete Image from a totally different source Application 
Object! 


Application Application 


Object _ bier 
eu A 32 bit Discrete B 


Image PA 

: Identifier = O1hex, : A 32 bit Analog 
oer Data = 4 bytes of I/O Data a ene Value 
Connection Connection 


Device #1 Device #2 


Application 


Object 
"D" 
Identifier = 01hex, . A 32 bit Discrete 
Data = 4 bytes of I/O Data un Image 
Connection 


Device #3 


Not one single approach can resolve these Connection ID-related error scenarios in all 
situations/systems. To reduce the likelihood of Connection ID related error scenarios, the 
following implementation guidelines must be followed: 


1. The allocation process must make every attempt to ensure that no two modules are capable 
of transmitting an identical bit pattern within the Connection Identifier Field. 


2. If possible, the deallocation process must ensure that all end-points of a Connection have 
timed out prior to re-using a Message ID. 


To further refine guideline #2, apply the following logic when the decision has been made to 
mark a previously allocated Message ID as available: 


e Ifthe Message ID is associated with a Connection that activates an Inactivity/Watchdog 
Timer, then a new Inactivity/Watchdog timer is activated. Upon expiration of this timer, 
the Message ID is marked as available. 

e Ifthe Message ID is associated with a Connection that does not activate an 
Inactivity/Watchdog Timer, then the assumption is made that this was taken into 
consideration when the Connection was established and the Message ID can be 
immediately marked as available. 
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Important: Realize that for a Connection using Transport Class 0 or a Connection whose 
expected_packet_rate attribute has been set to zero (0), guideline #2 cannot be met using logic 
based on that Connection Object alone. For example: 


e Ifthe Server end-point of a Transport Class 0 Connection experiences an 
Inactivity/Watchdog timeout, it cannot know the state of the Client based solely on this 
Connection. The Client could have just missed transmitting the message in a timely 
fashion and could still think the Connection is operating normally. 

e Ifthe Client end-point of a Connection whose expected_packet_rate has been set to 
zero (0) is deleted for some reason, the Server end-point(s) could still be active. 


For the types of connections discussed in the bullet list above, use caution when performing 
tasks that will result in the deallocation and possible re-use of the associated Message ID(s). 
(i.e., configuring the watchdog_timeout_action attribute to Auto Delete, manually Deleting a 
Connection Object via the transmission of the Delete service) 
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CONNECTION MANAGER OBJECT CLASS DEFINITION 
Class ID Code: 0x6 


The Connection Manager Class allocates and manages the internal resources associated with 
both I/O and Explicit Messaging Connections. The specific instance generated by the 
Connection Manager Class is referred to as a Connection Instance or a Connection Object. 
Connection Manager Object Class Attributes 


The Connection Manager Class attributes are defined below in Table 3-5.1. 


Table 3-5.1. Connection Manager Class Attributes 


Attribute Need In Access | Attribute | Data Type Attribute Semantics of 
ID Implementation Rule Name Description Values 


These class attributes are optional and are described in Chapter 4 of this specification. 


Connection Manager Object Class Services 


The Connection Manager Class supports the following CIP Common Services: 


Table 3-5.2. Connection Manager Class Services 


Service Need In Service Name Service Description 
Code Implementation 
Ol nex Get_Attribute All | Returns the contents of all attributes of the class. 


OE nex Conditional Get_Attribute_ Used to read a Connection Manager Class attribute value. 
Single This service is Required if any of the Connection Manager 
Class Attributes are supported. 


Class Level Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes All response is as follows: 


Byte Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
Revision (low byte) Default = 1 
Revision (high byte) Default = 0 

Max Instance (low byte) Default = 1 

Max Instance (high byte) Default = 0 

Max ID Number of Class Attributes (low byte) Default = 0 

Max ID Number of Class Attributes (high byte) Default = 0 

Max ID Number of Instance Attributes (low byte) Default = 0 

Max ID Number of Instance Attributes (high byte) Default = 0 


SID [Om JR JW IN JR [oO 


Important: Insert default values for all unsupported attributes. 


Connection Manager Object Instance Attributes 


The following list provides a summary of the Connection Manager Instance attributes and their 
associated data types. 
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Table 3-5.3. Connection Manager Object Instance Attributes 


Attr Need In Access | Attribute Name Data Description of Attribute Semantics 
ID_ | Implementation| Rule Type 
1 
2 


service requests received. 
Optional Set | Open Format Number of Forward Open 
Rejects service requests which were 
rejected due to bad format. 
3 Optional Set | Open Resource Number of Forward Open 
Rejects service requests which were 
rejected due to lack of 
resources. 


4 Optional Set | Open Other Number of Forward Open 
Rejects service requests which were 
rejected for reasons other 
than bad format or lack of 
resources. 
service requests received. 
6 Optional Set | Close Format Number of Forward Close 
Requests service requests which were 
rejected due to bad format. 
7 Optional Set | Close Other Number of Forward Open 
Requests service requests which were 
rejected for reasons other 
than bad format. 
8 Optional Set | Connection Number of connection 
Timeouts timeouts which have 
occurred. 


9 Optional Get |Connection Entry |STRUCT | Defines timing associated If the Connection Object 
List with this Connection (Class Code 0x05) is 
supported, the index value 
into the ConnOpenBits 
array is the Connection 
Instance number minus one 
(the first entry in the array, 
index value 0, is for 
Connection Instance 1). 
NumConnEntries UINT Number of connection Number of bits in the 
entries. This attribute, ConnOpenBits attribute. 
divided by 8 and rounded up 
for any remainder, gives the 
length of the array (in bytes) 
of the ConnOpenBits field 
of this structure. 
ConnOpenBits ARRAY _ | List of connection data 0 = Connection Instance is 
of which may be individually Non-Existent. 
BOOL queried by the Get/Search 1 = Connection Instance is 
Connection Data Services. Existent. Query for more 
Each bit represents a possible | information. 
connection. 


10 | Reserved/Obsolete 


7 tenths of a percent. representing 0 to 100%. 
12 | Optional Get | MaxBuffSize! UDINT Amount of buffer space | Size in bytes 
| ee een eee 
Optional Get | BufSize UDINT Amount of buffer space | Size in bytes 
Remaining! available at this time. 


' The meaning of, and method of calculating, these values are vendor specific. 


° 
—< 


= 
Ww 
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3-5.4 Connection Manager Object Instance Common Services 


The Connection Manager Object Instance supports the following CIP Common services: 


Table 3-5.4. Connection Manager Object Instance Common Services 


Service Need In Service Name Service Description 
Code _ | Implementation 


Olnex | Optional Get_Attribute_All Returns the contents of all attributes of the class. 


OEnex | Conditional Get_Attribute Single | Used to read a Connection Manager Objectinstance attribute. 
This service is Required if any of the Connection Manager 
Instance Attributes are supported. 

10hex Used to modify a Connection Manager Object instance 
attribute. 


3-5.4.1. Instance Level Get_Attributes_All Response 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes_All response is as follows. This service shall only return 
values of supported attributes. Therefore, a device can only return values up to the last 
consecutive supported attribute starting from the first attribute (Attribute 1). Values from any 
attributes supported beyond these must be acquired via a Get_Attribute Single service. 


Byte Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
0 Open Requests (low byte) 
1 Open Requests (high byte) 
2 Open Format Rejects (low byte) 
3 Open Format Rejects (high byte 
4 Open Resource Rejects (low byte 
5 Open Resource Rejects (high byte 
6 Open Other Rejects (low byte) 
7 Open Other Rejects (high byte) 
8 Close Requests (low byte) 
9 Close Requests (high byte) 
10 Close Format Rejects (low byte) 
11 Close Format Rejects (high byte) 
12 Close Other Rejects (low byte) 
13 Close Other Rejects (high byte) 
14 Connection Timeouts (low byte) 
15 Connection Timeouts (high byte) 
16 Connection Entry List - NumConnEntries (low byte) 
17 Connection Entry List - NumConnEntries (high byte) 
18 Connection Entry List — ConnOpenBits (up to first 8 BOOLs) 
19 Connection Entry List — ConnOpenBits (up to second 8 BOOLs, if applicable) 


n Connection Entry List — ConnOpenBits (up to n'" 8 BOOLs, if applicable) 
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3-5.5 


3-5.5.1 


3-56 


Byte Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
n+] CPU_Utilization (low byte) 
n+2 CPU_Utilization (high byte) 
n+3 MaxBuffSize (low byte) 
n+4 MaxBuffSize 
n+5 MaxBuffSize 
n+6 MaxBuffSize (high byte) 
n+7 BufSize Remaining (low byte) 
n+8 BufSize Remaining 


n+9 BufSize Remaining 


n+10 BufSize Remaining (high byte) 


Important: There are no default values for unsupported attributes; all values returned are for 
supported attributes. 


Connection Manager Object Instance Object Specific Services 


The Connection Manager Object Instance supports the following Object Specific services: 


Table 3-5.5. Connection Manager Object Instance Object Specific Services 


Service Need In Service Name Service Description 

4B nex Closes a connection 

52hex Conditional Unconnected_Send | Unconnected Send Service. Only originating devices and 
Peers foerrerdl devices that route between links need to implement 

54x Opens a connection 


56nex Optional Get_Connection_Dat | For diagnostics of a connection 


a 
Sng For diagnostics of a connection 
Data 
59hex Reserved for definition of connection opens with a size larger 
than 504 bytes. 
SAnex 


Conditional Get_Connection_Ow | Determine the owner of a redundant connection 
ner 


Connection Manager Object Specific Service Parameters 


The object specific services of the Connection Manager Object share many of the same service 
parameters. These parameters are defined in this section and referenced in the object specific 
service definitions. 


The Forward Open and Forward Close services shall be sent using the UCMM or an 
unbridged (local) explicit messaging connection only. They shall not be sent over a bridged 
explicit messaging connection. This restriction is required since each node on a bridged 
connection needs to receive and process these services. On subnets which support UCMM 
messaging, the recipient (either a target or an intermediate node) shall support these services 
using the UCMM and, in addition, may support these services over a local explicit messaging 
connection. On subnets which do not support UCMM messaging, these services shall be sent 
using a local explicit messaging connection. See Chapter 10 for more details on bridging and 
routing. 
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3-5.5.1.1 


3-5.5.1.2 
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Network Connection Parameters 


The object specific services of the Connection Manager Object share many of the same service 
parameters. These parameters are defined in this section and referenced in the object specific 
service definitions. 


Network connection parameters shall be provided as a single 16-bit word that contains the 
fields in the following figure: 


15 14 13 12 11 | 10 9 & | av || © |S 4 i & i 2 yak |] 
Redundant | Connection | Reserved | Priority Fixed / Connection Size (in bytes) 
Owner Type Variable 


e Connection Size: The maximum size, in bytes, of the data for each direction (where 
applicable) of the connection. For a variable sized connection, the size shall be the 
maximum size of the buffer for any transfer. The actual size of the transfer for a 
variable connection shall be equal to or less than the size specified for the network 
connection. The maximum buffer size shall be dependent on the links that the 
connection traverses. 


Fixed / Variable: With a fixed size connection, the amount of data on each transmission 
shall be the size specified in the Connection Size parameter. With a variable size 
connection, the amount of data on each transmission may be a variable size, up to the 
size specified in the Connection Size parameter. 

0 = Fixed 
1 = Variable 


Priority: The priority shall be one of: 
00 = Low Priority 
01 = High Priority 
10 = Scheduled 
11 = Urgent 


Connection Type: 
00 = Null (may be used to reconfigure a connection) 
01 = Multicast 
10 = Point to Point 
11 = Reserved 


Redundant Owner 
The redundant owner bit in the OST direction shall be set (= 1) to indicate that more 
than one owner may be permitted to make a connection simultaneously. The bit shall 
be clear (= 0) to indicate an exclusive-owner, input only or listen-only connection. 


Reserved fields shall be set to zero 


Packet Interval 


The object specific services of the Connection Manager Object share many of the same service 
parameters. These parameters are defined in this section and referenced in the object specific 
service definitions. 
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Requested packet interval (RPI) 


The requested packet interval shall be the requested time between packets in microseconds. 
The format of the RPI shall be a 32-bit integer in microseconds. 


Actual packet interval (API) 


The actual packet interval shall be the actual time between packets in microseconds. The 
format of the API shall be a 32-bit integer in microseconds. 


Usage 


The requested packet interval shall be the time between packets requested by the receiving 
device. The value shall be used to allocate bandwidth at each of the producing nodes. The 
allocation of bandwidth may have to be adjusted when the actual packet rate or actual packet 
interval is returned, since it is possible for the two values to differ. The path time-out value at 
each of the intermediate and target nodes shall also be set to the connection time-out multiplier 
times the API. The RPI is therefore required for all connections. 


Scheduled priority 


For scheduled priority, the RPI shall be the packet rate of the repetitive data. On links that 
support bandwidth allocation, bandwidth shall be reserved for this packet. For scheduled 
priority, the data shall also be restricted to the specified packet rate, which means that if data 
arrives at an intermediate node faster than the specified packet rate, the node shall filter the 
packets to the specified rate. Since each node’s scheduled priority update rate is in discrete 
quanta, the Actual Packet Interval (API) may be smaller (more rapid) than the RPI. The path 
time-out value shall be set to the Connection Time-out multiplier times the API. 


High priority 


For high priority, the RPI shall be used to set the path time-out in the intermediate and target 
nodes. The RPI shall therefore be set to the slowest packet rate expected, which shall preclude 
having the connection close due to a path time-out. The longer the path time-out, the longer the 
time required to reclaim resources in the intermediate nodes as a result of faults in the network. 
Since the high priority is not guantsed at any of the nodes, the API shall equal the RPI. To 
maintain consistency, however, the time-out value shall again be set to the Connection Time- 
out multiplier times the API. 


Low priority 


For low priority, the RPI shall be used to set the path time-out in the intermediate and target 
nodes. The RPI shall therefore be set to the slowest packet rate expected, which shall preclude 
having the connection close due to a path time-out. The longer the path time-out, the longer 
the time required to reclaim resources in the intermediate nodes as a result of faults in the 
network. Since the low priority is not quantised at any of the nodes, the API shall equal the 
RPI. To maintain consistency, however, the time-out value shall again be set to the Connection 
Time-out multiplier times the API. 
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The Priority/Time_tick parameter determines the priority of the unconnected message and the 
time duration of a ‘tick’ (Tick Time) specified in the Time-out_ticks parameter. The bit fields 


are: 


Table 3-5.6 Priority/Time_tick Bit Definition 


jaa ee So (eee 4 3 2 1 0 
Priority 
Reserved 0 = Normal Tick Time 
1 = Reserved 


The Reserved and Priority fields shall be set to zero (0). The tick time shall be used in 
conjunction with the Time-out_ticks parameter value to determine the total time out value. The 


following formula is used: 


Actual Time Out value = 2°" x Time_out_tick 


If the tick time is 0000 (1 ms.), a Time-out_ticks value of 5 would translate into 5 ms. If the 


tick time is 0010 (4 ms.), a Time-out_ticks value of 5 would translate into 20 ms. The Tick 


Time value is enumerated in the following table. 


Table 3-5.7. Time Tick Value Enumeration 


Time Tick Value Enumeration 


Tick Time Time per Tick Max Time 
(binary) 

0000 1 ms 255 ms 
0001 2 510 
0010 4 1020 
0011 8 2040 
0100 16 4080 
0101 32 8160 
0110 64 16,320 
0111 128 32,640 
1000 256 65,280 
1001 512 130,560 
1010 1024 261,120 
1011 2048 522,240 
1100 4096 1,044,480 
1101 8192 2,088,960 
1110 16,384 4,177,920 
1111 32, 768 8, 355, 840 ms 


Time-out_ticks 


The Time-out ticks parameter shall be used to specify the amount of time the originating 
application shall wait for the transaction to be completed. When used with the Time Tick 
portion of the Priority/Time_tick field, a total timeout value can be calculated. 
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Timeout Algorithm 


The Priority/Time_tick and Time-out ticks parameters are used to convey timeout information 
as the request flows through interconnecting devices. The originator states how long it will 
wait for a response (total round trip time), and each intermediate device (e.g. CIP Router) 
subtracts twice the actual amount of time between the reception of the packet and when 
processing of the packet is actually started (e.g. internal queuing/processing times, etc.) when 
forwarding the unconnected message along. If a CIP Router can not determine specifically how 
much time to subtract, it shall subtract 512 milliseconds. Each intermediate device shall use 
this adjusted value as a timer for the resources used to manage the unconnected message and 
also to check to see if a timeout is imminent before forwarding the message. If a timeout is 
imminent, then the intermediate device returns an error response rather than just letting the 
originator timeout. Also, when an intermediate device times out, an error response is returned. 
In both cases all resources associated with that unconnected message are released. This 
facilitates the ability to know how far along the route the packet progressed before the timeout 
actually occurred, and also results in intermediate nodes not leaving resources assigned to a 
transaction that has already timed out. 


Connection Serial Number 


The connection serial number shall be a unique 16-bit value selected by the connection 
manager at the originator of the connection. The originator shall make sure that the 16-bit 
value is unique for the device. There shall be no other significance placed on the number by 
any other nodes in the connection path. The connection serial numbers shall be unique but do 
not have to be sequential. For example, an operator interface may have a large number of 
connections open at the same time, each with a unique number. The same values could be 
repeated at other operator interface stations. A possible implementation would be to have a 
connection list which points to the descriptor for each connection, and the connection serial 
number could be the index into the table. 


Vendor ID 


The vendor number shall be a unique number assigned to the various vendors of products. 
Each vendor has a unique number assigned. 


Originator Serial Number 


The originator serial number shall be a unique 32-bit value that is assigned to a device at the 
time of manufacture. This value shall be guaranteed to be unique for all devices manufactured 
by the same vendor. No significance shall be attached to the number. The combination of 
Vendor ID and Originator Serial Number shall be unique throughout the entire system. 


Connection Number 


The connection number shall be a 16-bit value that is assigned by the connection manager 
when a connection is opened. This value allows other nodes to obtain connection data from the 
connection manager. This number shall not be confused with the Connection Serial Number. 
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Connection Path Size 
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The connection path size shall be the length of the connection path in 16-bit words. The length 
of the connection path varies during the connection process, since each node in the connection 
path removes the current port segment and forwards only the remaining path segments to the 


next node. 


Connection Path 


The connection path parameter shall contain one or more encoded paths as required by a 
combination of the service and the value of other parameters within the service data. The 
format of the path(s) shall follow that as defined by the Message Router Object (Path). The 
first part of the connection path shall contain routing information, which may include port, 
network, and electronic key segments. Also, depending on the O2T_connection_parameters 
and T2O_connection_parameters fields and the presence of a data segment, one or more 
encoded application paths shall be specified. In general, the application paths are in the order 
of Configuration path, Consumption path, and Production path. However, a single encoded 
path can be used when configuration, consumption, and/or production use the same path. The 
following table shows the valid combinations and the implied meaning of the application paths. 
The application paths are relative to the target node. 


Table 3-5.8. Encoded Application Path Ordering 


Network Connection Data Number of Encoded Application Paths 
Parameters Segment 
Oto T T toO Present 1 2 3 
Connection Connection 
Type Type 
Null Null Yes Path is for Invalid Invalid 
Configuration. 
No Invalid Invalid Invalid 
Not Null Null Yes Path is for First path is for Invalid 
Configuration Configuration, 
and second path is for 
Consumption. Consumption. 
No Path is for Invalid Invalid 
Consumption. 
Null Not Null Yes Path is for First path is for Invalid 
Configuration Configuration, 
and Production. second path is for 
Production. 
No Path is for Invalid Invalid 
Production. 
Not Null Not Null Yes Path is for Invalid First path is for 
Configuration, Configuration, 
Consumption and second path is for 
Production. Consumption, 
third path is for 
Production 
No Path is for First path is for Invalid 
Consumption and | Consumption, 
Production. second path is for 
Production. 
Open DeviceNet Vendor Assoc. & ControlNet International 3-61 


Chapter 3: Communication Object Classes Volume 1: CIP Common Specification 


3-5.5.1.10 Network Connection ID 


3-5.5.1.11 


3-5.5.2 


3-62 


The Network Connection ID shall be link specific and shall not be related to the connection 
serial number, which is connection specific and the same over all the links. The fields of the 
Network Connection ID shall be used to set the screening mechanism for the specified link. 
The Network Connection ID is either a CIP Produced Connection ID or CIP Consumed 
Connection ID. 


A multicast CID shall not be reused until all connections associated with the CID have been 
closed or timed out; 


Transport Class and Trigger 


The transport class and trigger specify the type of transport required for the connection. This 
information shall not be used by the connection manager but passed on to the application. The 
application shall determine if the transport type is supported and if an instance of the required 
transport is available. See the transportClass trigger attribute of the Connection Object for the 
details of this parameter. 


Forward Open 


The Forward Open Service (Service Code = 54;,x) is used to establish a Connection with a 
Target Device. This service results in local connection establishment on each link along the 
path. The Forward Open request sets up network, transport, and application connections. An 
application connection consists of a single transport connection, and one or two network 
connections that are in turn comprised of multiple link connections. Each port segment in the 
connection path uses a link connection. The Forward Open service between two devices 
builds one or two link connections as specified by the network connection parameter and the 
requested packet intervals (RPI). Since up to two network connections can be required for a 
single transport connection, they are differentiated by the O>T and T>O designations; O>T 
means originator to target, and T>O means target to originator. 


A connection established to the Message Router object of the target (based on the Connection 
Path parameter in the Forward Open request) results in an Explicit Messaging type connection. 
The format of the data sent on this connection uses the Message Router Request/Response 
Format as defined in Chapter 2-4 of this specification. Connections established to any other 
application object result in an I/O type connection. See the Connection Object attribute 2 
(Instance Type). 
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Table 3-5.9. Forward Open Request 


Parameter Name Data Description 
Type 
Priority/Time_tick BYTE Used to calculate request timeout information. See 
below. 
Time-out_ticks SINT | Used to calculate request timeout information. See 
below. 


O_to_T Network Connection UDINT | Network Connection ID to be used for the local link, 
ID originator to target. This is the originator’s CIP 
Produced Connection ID. 

DINT | Network Connection ID to be used for the local link, 
target to originator. This is the originator’s CIP 
Consumed Connection ID. 

See Object Specific Service Parameters above. 


T_to_O Network Connection 
ID 


Connection Serial Number 


cicicic io Cc 
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Originator Vendor ID NT Vendor ID of the originating node. 
Originator Serial Number DINT | Serial Number of the originating node. 
Connection Timeout Multiplier SINT | See Object Specific Service Parameters above. 
Reserved octet Reserved 
octet 
octet 
O to TRPI UDINT | Originator to Target requested packet rate, in 
microseconds. 
O_to_T Network Connection WORD | See Object Specific Service Parameters above. 
Parameters 
T_to_ O RPI Target to Originator requested packet rate, in 
microseconds. 
T_to_O Network Connection WORD | See Object Specific Service Parameters above. 
Parameters 
Transport Type/Trigger See Object Specific Service Parameters above. 
Connection Path Size USINT | The number of 16 bit words in the Connection _Path 
eer | field. 
Connection_Path Padded | Indicates the route to the Remote Target Device. 


Success shall be returned when the connection requested has been established from this point 
forward in the path. This reply also shall indicate the connection serial number and the actual 
packet rate of the connection. Once the successful reply has been received, the connection 
shall be open from this point forward in the path. Targets shall wait at least 10 seconds after 
sending a successful response for the first packet on a connection. 
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Table 3-5.10. Successful Forward Open Response 


Parameter Name Data Description 


O_to_T Network UDINT Network Connection ID to be used for the local link, 

Connection ID originator to target. If chosen by the originator, then the 
value is echoed back. This is the target’s CIP Consumed 
Connection ID. 

T_to_O Network UDINT Network Connection ID to be used for the local link, 

Connection ID target to originator. If chosen by the originator, then the 
value is echoed back. This is the target’s CIP Produced 
Connection ID. 


Connection Serial Number INT Returns same value received in the Request packet. 
Originator Vendor ID NT Returns same value received in the Request packet. 
Originator Serial Number DINT Returns same value received in the Request packet. 


O to T API UDINT Actual packet rate, originator to target. A router shall 
use the lesser of this value and the T to _O API for the 
expected_packet_rate of the connection. 


T_to O API UDINT Actual packet rate, target to originator. A router shall 
ce | use the lesser of this value and the O_to_T API for the 
expected_packet_rate of the connection. 
Application Reply Size USINT Number of 16 bit words in the Application Reply field. 
Reserved Reserved 


Application Reply Application specific data 


The following format shall be used for all Forward Open failures. The requested connection 
shall not be established, and the object specific status words shall contain information about the 
reason for the failure. The remaining path_size shall contain the length of the path at the point 
the connection request failed. 


In the failure response, the remaining remaining _path_size shall be the “pre-stripped” size. 
This shall be the size of the path when the node first receives the request and has not yet started 
processing it. A target node may return either the “pre-stripped” size or 0 for the remaining 
remaining path_size. 


A duplicate Forward_Open service shall be defined as a Forward_Open service whose 
vendor_ID, connection_serial_number, and originator_serial_number match an existing 
connection’s parameters. If the duplicate Forward_Open service is a null Forward_Open 
service (defined as the connection type in both the OST and T>0 network connection 
parameter fields are NULL), then the Forward_Open service shall be forwarded to the 
application for further processing. Null Forward Open requests may be used to reconfigure the 
connection. The Connection Manager in the intermediate nodes need not allocate additional 
resources for a duplicate Forward Open request since the resources have already been 
allocated. Ifthe duplicate Forward Open request is not NULL, then a general status = 0x01, 
extended status = 0x0100 shall be returned. 
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Table 3-5.11. Unsuccessful Forward Open Response 


Parameter Name Data Description 
Type 


Connection Serial Number Returns same value received in the Request packet. 
Originator Vendor ID Returns same value received in the Request packet. 
Originator Serial Number Returns same value received in the Request packet. 
Remaining Path Size USINT This field is only present with routing type errors and 


indicates the number of words in the original route path 

(Connection_Path parameter of the Forward Open 

Request) as seen by the router that detects the error. 
Reserved Shall be set to zero. 


Forward Close 


The Forward Close Service (Service Code = 4Enex) is used to close a connection with a Target 
Device (and all other nodes in the connection path). The Forward_Close request shall remove a 
connection from all the nodes participating in the original connection. The Forward Close shall 
be sent between Connection Managers as specified in the connection path. The Forward Close 
request shall cause all resources in all nodes participating in the connection to be deallocated, 
including connection IDs, bandwidth, and internal memory buffers. 


If an intermediate node cannot find the connection that is to be closed (it may have timed out at 
the node), the Forward Close request shall still be forwarded to downstream nodes or the target 


application. 


Table 3-5.12. Forward Close Service Request 


Parameter Name Data Description 
Type 
Priority/Time_tick BYTE Used to calculate request timeout information. 
Time-out_ticks USINT Used to calculate request timeout information. 
Connection Serial Number | UINT Connection Serial Number of established connection. 
Originator Vendor ID UINT Vendor ID of the originating node. 
Originator Serial Number UDINT Serial Number of the originating node. 
Connection Path Size USINT The number of 16 bit words in the Connection Path field. 
Reserved USINT Reserved 
Connection Path Padded Indicates the route to the Remote Target Device. 
EPATH 


Forward Close service request shall be successful when a request is received whose Originator 
Vendor ID, Connection Serial Number, and Originator Serial Number match an existing 
connection’s parameters. Additional information provided by this service (ie, Connection Path) 
shall be ignored by the target. 


Success shall be returned when the connection has been deleted at the target. The originator, 


and each intermediate node along the path, closes the connection and releases resources 
associated with that connection when the success response is received. 
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Table 3-5.13. Successful Forward Close Response 


Parameter Name Data Type Description 


Connection Serial Number Returns same value received in the Request packet. 
Originator Vendor ID Returns same value received in the Request packet. 
Originator Serial Number Returns same value received in the Request packet. 
Application Reply Size Number of 16 bit words in the Application Reply field. 
Reserved Reserved 

Application Reply Application specific data 


Table 3-5.14. Unsuccessful Forward Close Response 


Parameter Name Data Type Description 


Connection Serial Number | UINT Returns same value received in the Request packet. 
Originator Vendor ID UINT Returns same value received in the Request packet. 


Originator Serial Number UDINT Returns same value received in the Request packet. 


Remaining Path Size USINT 
Reserved USINT 


Unconnected Send 


The Unconnected_Send service shall allow an application to send a message to a device 
without first setting up a connection. The Unconnected_Send service shall use the Connection 
Manager object in each intermediate node to forward the message and to remember the return 
path. The UCMM of each link shall be used to forward the request from Connection 
Manager to Connection Manager just as it is for the Forward_Open service; however, no 
connection shall be built. The Unconnected_Send service shall be sent to the local Connection 
Manager and shall be sent between intermediate nodes. When an intermediate node removes 
the last port segment, the message shall be formatted as a UCMM message and sent to the port 
and link address of the last segment. 


NOTE: The target node never sees the Unconnected_Send service but only a standard message arriving via the UCMM. 
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Table 3-5.15. Unconnected Send Service Parameters 


Parameter Name Data Type Description 


Priority/Time_ tick Used to calculate request timeout information. 
Time-out_ticks Used to calculate request timeout information. 
Message Request_Size Specifies the number of bytes in the Message Request. 
Message_Request! 
Service Service code of the request. 
Request _Path Size | USINT The number of 16 bit words in the Request_Path field (next 
Request_Path | Padded This is an array of bytes whose contents convey the path of 
EPATH the request (Class ID, Instance ID, etc.) for this transaction. 
Request_Data Service specific data to be delivered in the Explicit 
octet Messaging Request. If no additional data is to be sent with 
the Explicit Messaging Request, then this array will be 
empty. 
Pad Only present if Message _Request_Size is an odd value. 
Route Path Size The number of 16 bit words in the Route Path field. 
Reserved Reserved byte. Shall be set to zero (0). 
Route Path Indicates the route to the Remote Target Device. 


' This is the Message Router Request Format as defined in Chapter 2. 
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The Unconnected_Send reply shall be generated by the last intermediate node from the UCMM 
reply generated by the target node or by an intermediate node as the result of a UCMM time- 
out, a problem with the embedded message, or a problem with the Unconnected Service 
Request itself. The packet shall be routed from intermediate node to intermediate node using 
the information stored when the Unconnected_Send request was processed. The reply shall 
contain a header with status information about the request and a variable length reply generated 
by the target node. 


The application reply shall be the format of the Message reply from the target and shall contain 
error codes that resulted from the execution of the message by the application at the target 
node. 


The Reply Service code returned may be either the service code sent inside the Unconnected 
Send service data or the Unconnected Send service code. In either case, the upper bit is set to 
indicate a response. For example, if the requested service was a Get_ Attribute Single, then the 
response message may specify either Ox8E (Get_Attribute Single = 0xOE) OR 0xD2 
(Unconnected Send = 0x52). This assists a router by: 


e Allowing it to pass the original service code response back for a message which made it 
to the target (since the Unconnected Send does not appear at the target) 


e Not requiring it to parse the service code out of the Unconnected Send request when a 
failure occurs in the routing. 


The Service Data associated with a successful Unconnected Send response is: 


Table 3-5.16. Successful Unconnected Send Response 


Parameter Name Description 
Type 

Reply Service Reply service code. 

Reserved Shall be zero 

General Status USINT | This value is zero (0) for successful transactions. 

Reserved USINT | Shall be zero. 


Service Response Array of | This field contains the Explicit Messaging Service Data returned by the Target 
Data byte Device/Object. For example, this would contain Attribute Data in response to 
a Get_Attribute_ Single request. If the Explicit Messaging response returned by 
the Target Device/Object did not contain any Service Data, then this field shall 
be empty. 


The response Service Data associated with an unsuccessful Unconnected Send response is 
defined below. 
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Table 3-5.17 Unsuccessful Unconnected Send Response 


Parameter Name Data Description 
Type 

Reply Service USINT | Reply service code. 

Reserved USINT | Shall be zero. 


General Status USINT | One of the General Status codes listed in Appendix B Error Codes. Ifa routing 
error occurred, it shall be limited to the values specified in the Routing Error 
Values table. 

Size of Additional USINT | Number of 16 bit words in Additional Status array. 


Status 

Additional Status Array of | When returning an error from a target which is a DeviceNet node, the 
Additional Status shall contain the 8 bit Additional Error Code from the target 
in the lower 8 bits and a zero (0) in the upper 8 bits. 

Remaining Path USINT | This field is only present with routing type errors and indicates the number of 

Size words in the original route path (Route_Path parameter of the Unconnected 


Cc 
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Send Request) as seen by the router that detects the error. 


In order to standardize Routing Error handling in CIP Routers, the following table presents the 
possible Routing Errors and when/why they would be returned. In each of these cases the 
Remaining Path Size parameter is present. This list entails the ONLY Routing Errors that a 
CIP Router can return. 


Table 3-5.18. Routing Error Values 


General Additional Usage 
Status Status 
01 0204 hex Timeout indicator. Returned under the following circumstances: 

e Failure to establish an Explicit Messaging Connection. 

e Timeout event occurs while waiting for an Explicit Messaging Response. 

e After decreasing the timing parameters when an Unconnected Send 
request is received, the CIP Router determines that there is not enough 
time left to continue this transaction (a Requesting Device timeout is 


imminent). 
01 031 Ihex Invalid Port ID specified in the Route Path field. 
Ol 031 2nex Invalid Node Address specified in the Route Path field. 
01 0315 nex Invalid segment type in the Route_Path field. 
02 empty Resource error. The CIP Router lacks the resources to fully process the 
Unconnected Send Request. 
04 empty Segment type error. Indicates the CIP Router experienced a parsing error when 


extracting the Explicit Messaging Request from the Unconnected Send Request 
Service Data. 


Get Connection Data 


This service shall return the parameters associated with a specified connection number. The 
connection_number may be different from device to device even for the same connection. The 
connection number corresponds to the offset into the Connection Manager attribute that 
enumerates the status of the connections. 


Table 3-5.19. Get Connection Data Service Request 


Parameter Name Description 


Connection Number Connection number 
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Table 3-5.20. Get Connection Data Service Response 


Parameter Name Description 
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Connection Number 
Connection State IN 
Originator Port UINT 
Target Port 
Connection Serial UINT Connection Serial Number of established connection. 
Number 
Originator Vendor ID UINT Vendor ID of the originating node. 
Originator Serial UDINT Serial Number of the originating node. 
Number 
Originator O2T CID UDINT 
Target O2T CID 
Connection Timeout USINT 
Multiplier apa 
Reserved USINT 
USINT 
USINT 
Originator RPI O2T 
Originator API O2T 
Originator T20 CID 
Target T20 CID UDINT 
Connection Timeout USINT 
Multiplier 
Reserved USINT 
USINT 
USINT 
Originator RPI T20 
Originator API T2O 


3-5.5.6 Search Connection Data 


The Unconnected_Send service shall allow an application to send a message to a device 


Table 3-5.21. Search Connection Data Service Request 


Parameter Name Data Description 
Type 


Connection Serial Number | UINT Connection Serial Number of established connection. 
Originator Vendor ID UINT Vendor ID of the originating node. 
Originator Serial Number UDINT Serial Number of the originating node. 


3-5.6 Connection Manager Object Instance Error Codes 
3-5.6.1 Error Code Listing 


The error codes are returned with the reply to a Connection Manager Service Request that 
resulted in an error. These error codes shall be used to help diagnose the problem with a 
Service Request. The error code shall be split into an 8 bit general status and one or more 16- 
bit words of extended status. Unless specified otherwise, only the first word of extended status 
shall be required. Additional words of extended status may be used to specify additional 
module specific debug information. All devices that originate messages shall be able to handle 
multiple words of extended status. 
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The following table provides a summary of the available error codes. 


Table 3-5.22. Connection Manager service request error codes 


General Extended Explanation 

Status Status 

0x00 Service completed successfully. 

0x01 0x0100 Connection in Use or Duplicate Forward Open. 

0x01 0x0103 Transport Class and Trigger combination not supported 

0x01 0x0106 Ownership Conflict 

0x01 0x0107 Connection not found at target application. 

0x01 0x0108 Invalid Connection Type. Indicates a problem with either the Connection 
Type or Priority of the Connection. 

0x01 0x0109 Invalid Connection Size 

0x01 0x0110 Device not configured 

0x01 0x0111 RPI not supported. May also indicate problem with connection time-out 
multiplier, or production inhibit time. 

0x01 0x0113 Connection Manager cannot support any more connections 

0x01 0x0114 Either the Vendor Id or the Product Code in the key segment did not match 
the device 

0x01 0x0115 Product Type in the key segment did not match the device 

0x01 0x0116 Major or Minor Revision information in the key segment did not match the 
device 

0x01 0x0117 Invalid Connection Point 

0x01 0x0118 Invalid Configuration Format 

0x01 0x0119 Connection request fails since there is no controlling connection currently 
open. 

0x01 Ox011A Target Application cannot support any more connections 

0x01 0x011B RPI is smaller than the Production Inhibit Time. 

0x01 0x0203 Connection cannot be closed since the connection has timed out 

0x01 0x0204 Unconnected Send timed out waiting for a response. 

0x01 0x0205 Parameter Error in Unconnected Send Service 

0x01 0x0206 Message too large for Unconnected message service 

0x01 0x0207 Unconnected acknowledge without reply 

0x01 0x0301 No buffer memory available 

0x01 0x0302 Network Bandwidth not available for data 

0x01 0x0303 No Tag filters available 

0x01 0x0304 Not Configured to send real-time data 

0x01 0x0311 Port specified in Port Segment Not Available 

0x01 0x03 12 Link Address specified in Port Segment Not Available 

0x01 0x0315 Invalid Segment Type or Segment Value in Path 

0x01 0x03 16 Path and Connection not equal in close 

0x01 0x0317 Either Segment not present or Encoded Value in Network Segment is 
invalid. 

0x01 0x0318 Link Address to Self Invalid 

0x01 0x0319 Resources on Secondary Unavailable 

0x01 0x031A Connection already established 

0x01 0x031B Direct connection already established 

0x01 0x031C Miscellaneous 

0x01 0x031D Redundant connection mismatch 
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General Extended Explanation 
Status Status 
0x01 0x031E No more consumer resources available in the producing module 
0x01 0x031F No connection resources exist for target path 
0x01 0x320— | Vendor specific 
Ox7FF 
0x02 n/a Connection Manager resources are unavailable to handle service request 
0x03 n/a Invalid connection number specified by the Get_Connection_Data service. 
This is also returned by the Search _Connection_Data service if the 
specified connection is not found. 
0x04 Zero Based | Segment Type in path is invalid. The Extended Status shall be the word 
Word offset (0 based) to the word in the path where the error occurred. The 
Offset offset starts at the first word after the path size. This error shall not be 
retumed if an error occurs when parsing the Connection Path. 
0x05 Zero Based | Destination in path is invalid. The Extended Status shall be the word offset 
Word (0 based) to the word in the path where the error occurred. The offset starts 
Offset at the first word after the path size. This error shall not be returned if an 
error occurs when parsing the Connection Path. 
0x07 n/a Connection has been lost. This is used by the Get/Set Services when they 
are made through a connection. 
0x08 n/a Connection Manager does not support the requested Service. 
0x09 Index to Error in Data Segment. Extended Status shall be index to where the error 
Element | was encountered in the Data Segment. The Configuration Revision 
Number if present in the Data Segment shall always be index 1. 
If the error occurs with the Get/Set Services, then the extended status 
indicates the attribute number that failed. 
0x0C Optional | Service cannot be performed while Object is in current state. The lst word 
of Extended Status may optionally contain the object’s current state. 
0x10 Optional | Service cannot be performed while Device is in current state. The lst word 
of Extended Status may optionally contain the device’s current state. 
Ox11 n/a Response data too large. This is used by the get services to indicate the 
amount of data requested was too large to fit into the response buffer. 
0x13 n/a Not enough data was received. 
0x14 Attribute Id | Attribute specified in FIND service is not supported by Connection 
Manager 
Ox15 n/a Too much data was received. 
0x25 0x0114 Either the Vendor Id or the Product Code in the key segment did not match 
the device. Used if the Key Segment was contained in the path. 
0x25 0x0115 Product Type in the key segment did not match the device. Used if the Key 
Segment was contained in the path. 
0x25 0x0116 Major or Minor Revision information in the key segment did not match the 
device. Used if the Key Segment was contained in the path. 
0x26 n/a Invalid path size 


NOTE: The word “n/a” in the Extended Status Column is used to signify that there is no 
additional Extended Status which is required to be returned for the particular General 


Status Code. 


The word “optional” in the Extended Status Column is used to signify that if Extended 
Status information is used, then the first word of that extended status is already defined 
and user defined extended status shall begin with the second word of extended status. 
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General Status Code 0x01 
Usage 


This general status code shall be returned if there is a problem with a parameter in a service 
request to the connection manager. The following sections shall provide details of the specific 
extended status codes that are to be returned with the general status. 


Connection in use (extended status = 0x0100) 


This extended status code shall be returned when an originator is trying to make a connection 
to a connection point with which the originator may have already established a connection 
(duplicate Forward Open). This may result from the originator establishing a connection with 
a connection point and the success response being lost in the return path. The originator shall 
then time-out on the request and attempt to establish the connection again even though the 
target actually established the connection. 


The suggested response from the originator in this case shall be to either close and establish the 
connection again or wait for the connection to time-out and then establish the connection again. 
It shall be recognised that in the latter case, it shall take the connection 60 seconds (first data 
time-out) to time-out before the connection can be re-established. 


A duplicate forward open shall be defined as an open request that has the same connection 
serial number, vendor ID, and originator serial number as a connection on the target that is 
already open. If an intermediate node receives a duplicate Forward Open request, then the 
intermediate node shall pass on the request. However, the intermediate node shall not need to 
allocate transport resources for a new connection. 


Transport/trigger not supported (extended status = 0x0103) 


A transport class and trigger combination has been specified which is not supported by the 
application. Although routers may use the transport/trigger field, they shall not fail the 
connection based on its contents. Only targets shall return this extended status code. 


Ownership conflict (extended status = 0x0106) 


The connection cannot be established since another connection already "owns" some of the 
resources required for this connection. An example of this would be that only one connection 
can control an output point on an I/O Module. Ifa second controlling connection is attempted, 
this error shall be returned. This extended status code shall only be returned by a target node. 


Connection not found at target application (extended status = 0x0107) 


This extended status code shall be returned by the close connection request, where the 
connection which is to be closed is not active at the target node. This extended status code 
shall only be returned by a target node. An intermediate node shall not generate this extended 
status code. Ifthe specified connection is not found at the intermediate node, the close request 
shall still be forwarded using the path specified in the Forward_Close request. 
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Invalid connection type (extended status = 0x0108) 


This extended status code shall be returned as the result of specifying a connection type 
(including fixed/variable sized connection) or connection priority which is not supported by the 
target application. Only a target node shall return this extended status code. 


Invalid connection size (extended status = 0x0109) 


This extended status code is returned when the target or router does not support the specified 
connection size. This could occur at a target because the size does not match the required size 
for a fixed size connection. It could occur at an intermediate device if the requested size is too 
large for the specified network. 


Device not configured (extended status = 0x0110) 


This extended status code shall be returned when a connection is requested from a target 
application that has not been configured and the connection request does not contain a data 
segment for configuration. Only a target node shall return this extended status code. 


RPI not supported (extended status = 0x0111) 


This extended status code shall be returned if the device can not support the requested OST or 
TSO RPI. This extended status code shall also be used if the connection time-out multiplier 
produces a time-out value that is not supported by the device. 


Connection Manager out of connections (extended status = 0x0113) 


The maximum number of connections allowed by this instance of the Connection Manager has 
been exceeded. 


Vendor Id or Product Code error (extended status = 0x0114) 


The Product Code or Vendor Id specified in the electronic key logical segment does not match 
the Product Code or Vendor Id in the target device. 


Product Type error (extended status = 0x0115) 


The Product Type specified in the electronic key logical segment does not match the Product 
Type in the target device. 


Revision mismatch (extended status = 0x0116) 


The major and minor revision information in conjunction with the exact match bit specified in 
the electronic key logical segment does not correspond to a valid revision for this device. 


Invalid connection point (extended status = 0x0117) 


The connection point specified in the connection path does not correspond to a valid 
connection point for the target application. This error could also be returned if a connection 
point was required, but not provided by a connection request. 
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Invalid configuration format (extended status = 0x0118) 


An instance number specified for the configuration data does not correspond to a configuration 
instance. For example the connection path specifies a float configuration when the connection 
points specify a raw connection. This extended status code shall be used when the logical 
instance segment in the connection path is used to indicate a configuration type instead of an 
instance. 


Controlling connection not open (extended status = 0x0119) 


The extended status code shall be returned when an attempt is made to establish an echo (i.e. 
listen only) connection to a connection which has no controlling connection (i.e. owner). 


Application out of connections (extended status = 0x011A) 


The maximum number of connections supported by this instance of the Target Application has 
been exceeded. 


For example, the Connection Manager could support 20 connections while the Target 
Application can only support 10 connections (there may be other Target Applications that an 
originator can connect to). On the 11th Connection Request to the Target Application, this 
extended status code would be used to signify that the Target Application is out of 
Connections. 


Connection timed out (extended status = 0x0203) 


This extended status code shall occur when a client tries to send a connected message over a 
connection that has been timed-out. This extended status code shall only occur at the 
originating node. 


Unconnected send timed out (extended status = 0x0204) 


The Unconnected Send Timed Out shall occur when the UCMM times out before a reply is 
received. This may occur for an Unconnected_Send, Forward_Open, or Forward_Close 
service. This means that the UCMM has tried a link specific number of times using a link 
specific retry timer and has not received an acknowledgement or reply. This may be the result 
of congestion at the destination node or may be the result of a node not being powered up or 
present. This extended status code shall be returned by the originating node or any 
intermediate node. 


Parameter error in unconnected send service (extended status = 0x0205) 

One of the parameters in the unconnected send service was in error. 

This shall be caused by an invalid Connection Tick Time and Connection time-out combination 
when an intermediate node attempts to decrement this value before passing the 


Unconnected_ Send, Forward Open, or Forward Close service on to the next node in the path. 


This shall also be caused when the Unconnected_Send is too large to be sent out on a network 
connection. 
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Message too large for unconnected message service (extended status = 0x0206) 


The message to be sent via the unconnected message service was larger than fits in the buffers 
allocated for the unconnected send service. This extended status code can only be detected by 
the originating node. 


Unconnected acknowledge without reply (extended status = 0x0207) 


The message to be sent via the unconnected message service was acknowledged but not 
responded to. 


No buffer memory available (extended status = 0x0301) 


The extended status code shall occur when insufficient memory is available to allocate a 
connection buffer. Routers and target nodes shall detect this error. 


Bandwidth not available (extended status = 0x302) 


This extended status code shall be returned by any device in the path that is a producer and can 
not allocate sufficient bandwidth for the connection on its link. This can occur at any node. 
This can only occur for connections that are specified as scheduled priority. 


No screeners available (extended status = 0x0303) 


Any device in the path that is a consumer and does not have a screener available shall detect 
this extended status code. 


Not configured to send real-time data (extended status = 0x304) 


If requested to make a scheduled connection, any device that is unable to send scheduled 
packets shall return this extended status code. For example, this code shall be returned by a 
node whose MAC ID is greater than SMAX. 


Port not available (extended status = 0x0311) 
This extended status code is the result of specifying a non-existent port in a port segment. 


Link address not available (extended status = 0x0312) 


This extended status code is the result of a port segment that specifies an invalid link address. 
This extended status code shall not be used for valid link addresses that do not respond. 


Invalid segment type in path (extended status = 0x0315) 


This extended status code is the result of a device being unable to decode the connection path. 
This could be caused by an unrecognised path type, a segment type occurring unexpectedly, or 
a myriad of other problems. 
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3-5.6.2.30 Error in close path (extended status = 0x0316) 


The path in the close service does not match the connection being closed. This means the 
connection points to a different module or application than is specified in the path. The 
connection is deleted but the error message shall be returned. 


3-5.6.2.31 Scheduling not specified (extended status = 0x0317) 


Either a Schedule Segment was expected in the path and not found, or the Encoded Value in 
the Schedule Segment was zero (i.e. invalid). 


3-5.6.2.32 Link address to self invalid (extended status = 0x0318) 


Under some conditions (depends on the device), a link address in the Port Segment which 
points to the same device (loopback to yourself) is invalid. 


3-5.6.2.33 Secondary resources unavailable (extended status = 0x0319) 


In a dual chassis redundant system, a connection request that is made to the primary system 
shall be duplicated on the secondary system. If the secondary system is unable to duplicate the 
connection request, then this extended status code shall be returned. 


3-5.6.2.34 Connection already established (extended status = 0x031A) 


A request for a direct connection has been refused because the corresponding data is already 
included in a larger block of data being sent via another connection. 


3-5.6.2.35 Direct connection already established (extended status = 0x031B) 


A request for a connection has been refused because a member of the corresponding data is 
already being sent via a direct connection. 


3-5.6.2.36 Miscellaneous (extended status = 0x031C) 


Essentially, if no other extended status code applies, then return this one. 


3-5.6.2.37 Redundant connection mismatch (extended status = 0x031D) 


This extended status code shall be returned when establishing a redundant owner connection 
without matching the following fields in the Forward_Open to the same fields in the other 
redundant owner connections to the same target path: 

e O2T_RPI; 

e O2T_connection_parameters; 

e T2O_RPI; 

e T20_connection_parameters; 


e xport_type_and_trigger. 
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No more consumer resources available in the producing module (extended status 
= 0x031E) 


A node that was configured to consume data from a producing node can display this error if the 
producing node was not configured to support enough consumers. 


No connection resources exist for target path (extended status = 0x031F) 


A node that was configured to consume data from a producing node can display this error if the 
data on the producing node was not configured to be produced. 

General status code 0x02 

This general status code shall be returned when the Connection Manager object lacks the 
resources to handle a connection request. 

General status code 0x03 


This general status code shall be returned by the Get_Connection_Data request when the 
connection number supplied with the service is invalid (i.e. no connection is present). This 
general status code is also returned by the Search _Connection_Data service when the 
connection specified by the Connection Serial Number, Vendor Id, and Originator Serial 
Number is not found at the target. 

General status code 0x04 


This general status code shall be returned when there is a problem with the Segment Type in 
the path of a service request. The extended status provides a zero based 16-bit word offset to 
the place where the error occurred. The offset begins with the first word after the path size in 
the message. 

General status code 0x05 


This general status code shall be returned when there is a problem with the Destination in the 
path of a service request. The extended status provides a zero based 16-bit word offset to the 
place where the error occurred. The offset begins with the first word after the path size in the 
message. 


General status code 0x07 


The general status code shall be returned by the following services if the requests were made 
via a message router connection and the connection had been closed: 


e Get_Attribute_All 

e Set_Attribute All 

e Get Attribute Single 
e Set Attribute Single 
e Get Attribute List 

e Set_Attribute_List 
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General status code 0x08 


This general status code shall be returned when the connection manager object on a particular 
device does not support the requested service. 


General status code 0x09 


This general status code shall be returned when there is an error in the data segment. The 
extended status shall provide an indication of the problem. When this general status code is 
returned in response to a find or Set_Attributes_All request, the extended status shall indicate 
the attribute number of the first attribute that caused the error. 


General status code 0x0C 


This general status code shall be returned when the state of the target application prevents the 
service request from being handled. The first word of Extended Status can report the object's 
current state. The extended status is considered optional and is not required. 


For example, an object may need to be in an edit mode before attributes can be set. This is 
different from a service being rejected due to the state of the device, as in 3-5.6.11 (General 
status code 0x10). 


General status code 0x10 


This general status code shall be returned when the state of the device prevents the service 
request from being handled. The first word of Extended Status can report the device's current 
state. For the Connection Manager object, the extended status is considered optional and is not 
required. 


For example, a controller may have a key switch which when set to the "hard run" state causes 
Service Requests to several different objects to fail (i.e. program edits). This general status 
code would then be returned. 


General status code 0x11 


This general status code shall be returned by services to indicate that the response buffer is not 
large enough to hold the data, which was requested by the service. This applies in particular to 
Get_Connection_Data, Search_Connection_Data, Get_Attribute_All, Get_Attribute List, and 
Get_Attribute_Single services. 


General status code 0x13 


This general status code shall be returned when not enough data was provided to perform a 
service request. This could mean that there wasn't enough data in the Connection Path or the 
size of the message was too small to even route the message to the appropriate object. 


General status code 0x14 


This general status code shall be returned by the find service when an attribute included in the 
service is not defined for the Connection Manager. The extended status shall indicate the 
attribute number of the first attribute that caused the error. 
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General status code 0x15 


This general status code shall be returned when too much data was provided to perform a 
service request. This could mean that there was too much data in the Connection Path or the 
size of the message was greater than expected for a given service request. 


General status code 0x25 
Usage 


This general status code shall be returned if the electronic key logical segment is included as 
part of the path and a problem was detected with the data contained in the electronic key logical 
segment. The extended status shall provide details of the error. This general status code shall 
not be returned if the electronic key logical segment was part of the connection path. In that 
case, general status 0x01 (Connection Failure) would be returned. This section provides details 
of the specific extended status codes that are to be returned. 


Vendor Id or Product Code error 0x0114 


The Product Code or Vendor Id specified in the electronic key logical segment does not match 
the Product Code or Vendor Id in the target device. 


Product Type error 0x0115 


The Product Type specified in the electronic key logical segment does not match the Product 
Type in the target device. 


Revision mismatch 0x0116 


The major and minor revision information in conjunction with the exact match bit specified in 
the electronic key logical segment does not correspond to a valid revision for this device. 


General status code 0x26 


This general status code shall be returned when the path size is invalid. This could mean that 
not enough or too much data is contained in the path to correctly specify the destination of a 
service request. 
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APPLICATION CONNECTION TYPE USING CLASS 0 OR 1 
TRANSPORTS 


The Forward Open service of the Connection Manager provides the ability to create two 
network connections at the same time, one Class 0/1 connection in the O=>T direction and the 
other Class 0/1 connection in the T=>O direction. When two connections are created in the 
same Forward Open service request certain behaviors are associated between the two 
connections depending on their application connection type. 


The application type shall determine the target behaviour concerning the relationship between 
different connections each sharing a producer, and shall be one of LISTEN ONLY, 
INPUT_ONLY, EXCLUSIVE OWNER, or REDUNDANT _OWNER. 


Listen only 


If a connection has an application type of listen only, it shall be dependent on another 
connection for its existence. Devices that wish to listen to multicast data without providing 
configuration or scheduling information may use this application type. If the connection on 
which a listen only connection depends is closed or times out, the listen only connection shall 
also be closed. 


Input only 


If a connection has an application type of input only, it shall not be dependent on any other 
connection for its existence. For scheduled input only connection, the Forward_Open path shall 
contain a schedule segment. No O>T data shall be sent; therefore, a target may accept many 
input only connections. A specific implementation may limit the number of input only 
connections it accepts. 


Exclusive Owner 


If a connection has an application type of exclusive owner, it shall not be dependent on any 
other connection for its existence. For scheduled exclusive owner connections, the 
Forward_Open path shall contain a schedule segment. O>T data that controls outputs may be 
present; therefore, a target may only accept one exclusive owner connection. In addition, the 
target may accept listen only and input only connections that use the same multicast T>O data. 


The term connection owner shall refer to the connection originator whose O>T packets are 
being consumed by the target object. The term owning connection shall refer to the connection 
associated with connection owner. 


Exclusive owner connections are the most common application type for controller to I/O connections since they 
allow the controller to receive inputs and control outputs on the same connection. 
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Redundant owner 
General 


The redundant owner connection shall allow multiple separate originator applications to each 
establish an independent, identical connection to the transport of a target application. The 
target transport shall in turn send events to the target application so that the redundant owner 
connection appears as a single, exclusive owner connection to the target application. At most 
one of the originator applications shall have its data applied to the target application. The 
target transport shall multicast the target application data to each of the originator applications. 


The redundant owner connection may commonly be used in applications where up time is at a premium. In these 
applications, multiple originator applications can each establish a connection to a target application (typically an 
output application). Should an originator application fail or otherwise give up control, another originator application 
can quickly have its data applied to the target application without having to establish a connection with the target. 


Establishing the Connection 


A redundant owner connection and an exclusive owner connection shall not both be established 
to a target application at the same time. Multiple redundant owner connections may be 
established to the same target simultaneously provided that the following fields of the 

Forward Open request are identical and the connection paths match. The connection path shall 
match including any data segments. 


e O2T_RPI; 

e O2T_connection_parameters; 
e T20_ RPI; 

e T2O_connection_parameters; 
e xport_type_and_trigger. 


The target shall return general status = 0x01 and extended status = 0x031D if any of these 
fields do not match. 


The target transport shall only send the CM_open_indication to the target application when the 
first Forward_Open is received. Subsequent redundant Forward_Opens shall not cause a 
CM_open_indication to be sent to the target application. 


Bit 15 of the Forward Open request.O2T_connection_parameters specifies whether the connection is an exclusive 
owner or redundant owner connection 


Redundant owner O=>T data format 


General 


Redundant owner shall have a 32-bit header prefixed to the real-time data. 
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Claim Output Ownership (COO) Flag 


The COO flag shall be set (1) when an originator application wants its connection to be the 
owning connection of the target application. The COO flag shall be reset (0) when an 
originator application does not want its connection to be the owning connection of the target 
application. When the owning connection resets (0) its COO flag, its sibling connections shall 
be checked for a set (1) COO flag. The new owner shall be any of the connections that have 
their COO flag set. 


This results in undefined behaviour if more than one other connection has its COO flag set. 


Ready for Ownership of Outputs (ROO) Priority Value 


The ROO priority value shall be non-zero when an originator application does not want to force 
its connection to be the owning connection of the target application, but is ready to be the 
owning connection should there be no originator applications claiming to be the owning 
connection. The ROO priority value shall be zero when the originator application does not 
want to be the owning connection of the target connection and is not to be the owning 
connection should there be no originator application claiming to be the owning connection. 

The ROO priority value shall be used only when the COO flag is reset. 


The value of the ROO field can range from 0 to 3. The originator applications shall each 
determine a unique non-zero ROO value. 


Determining the owning connection 


The originator applications shall determine among themselves which originator application has 
the owning connection. The owning connection shall be determined by the originator 
application that sets its COO flag. In situations where multiple originator applications have 
their COO flag set or where no originator connections have their COO flag set, the following 
rules shall be applied by the target transport to determine the owning connection. 


e There shall be no owning connection until an originator application sends a real-time 
packet with the COO flag set; 

e If there is only one originator application which had the COO flag set in its last real- 
time packet, that originator application shall have the owning connection; 

e Ifthere are multiple originator applications which had the COO flag set in its last real- 
time packet, the last originator application that transitioned its COO flag from reset to 
set shall have the owning connection. 

e Ifthe originator application with the owning connection resets its COO flag, closes its 
connection, or if that connection times out, and no other originator applications have 
their COO flags set, the originator application with the highest non-zero ROO priority 
value shall have the owning connection. 

e Ifall of the originator applications have their COO flags reset and ROO priority values 
set to zero, there shall be no owning connection. 

e When the first real-time packet containing a set COO flag is received by the target 
transport, the originator application that sent the real-time packet shall have the owning 
connection. 
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Transporting events and data to a target application 


The connection related events from each of the redundant owner connections shall be combined 
using the following rules such that the target application sees only a single exclusive owner 
connection: 


e Until an owning connection is initially determined, the transport shall not indicate real- 
time data reception to the target application; 

e Ifan owning connection is determined, the transport shall indicate the event consistent 
with the owning connections real-time data to the target application. If the Run/Idle 
flag is reset in the real-time data for the owning connection, the transport shall indicate 
the idle state to the target application. If the Run/Idle flag is set in the real-time data for 
the owning connection, the transport shall indicate the run state and the real-time data to 
the target application; 

e Ifan owning connection had been previously determined, but no originator is currently 
claiming or ready for ownership, the transport shall indicate idle state to the target 
application; 

e  Ifall the redundant connections are closed or have been timed out, the target transport 
shall indicate the event consistent with the last connection to have been closed or timed 
out to the target application. 


RUN/IDLE Notification 


Applications which require RUN/IDLE notification via O=>T and/or T=>O network 
connections shall use at least one of the following real-time transfer formats: 


e 32-bit header, with fixed or variable size network connection; 
e no header, with variable size network connection. 


The 32-bit header prefixed to the real-time data shall be the following form: 


Bits 4-31 Bits 2-3 Bit 1 Bit 0 


Reserved ROO COO Run/Idle 


The run_idle flag (bit 0) shall be set (1 = RUN) to indicate that the following data shall be sent 
to the target application. It shall be clear (0 = IDLE) to indicate that the idle event shall be sent 
to the target application. The ROO and COO fields (bits 1-4) are defined in 3-7, Redundant 
Owner. The reserved field (bits 4-31) shall be reserved and set to 0. 


If the no header transfer format is used, the reception of a packet with data beyond the transport 
header shall indicate the RUN mode. If the packet is truncated after the transport header, the 
target application shall be sent an idle event. The real-time transfer formats described in this 
section shall only apply to transport types LISTEN ONLY, INPUT_ONLY and 

EXCLUSIVE OWNER. The real-time transfer formats for the REDUNDANT_OWNER 
transport type is described in 3.5. 
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3-7 PORT OBJECT CLASS DEFINITION 
Class Code: F4 hex 


The Port Object enumerates the CIP ports present on the device. One instance exists for each 
CIP port. 


3-7.1 Port Object Class Attributes 


The Connection Manager Class attributes are defined below in Table 3-7.1. 
Table 3-7.1. Port Class Attributes 


Attr Need In Access Attribute Data Type Attribute Description Semantics of 
ID_| Implementation | Rule Name Values 


1__| This class attribute is optional and is described in Chapter 4 of this specification. 


Instance number. 
; 
Instances currently instantiated. 


4—7 | These class attributes are optional and are described in Chapter 4 of this specification. 


g Required Get Entry Port |UINT Returns the instance of 
the Port Object that 
describes the port 
through which this 
request entered the 
device. 


: = 


containing instance 
3-7.2 Port Object Class Services 


attributes | and 2 from 
each instance. The 
The Port Class supports the following CIP Common Services: 


array is indexed by 
instance number, up to 
the maximum number 
of instances. The 
values at index 1 
(offset 0) and any non- 
instantiated instances 
shall be zero. 


Table 3-7.2. Port Class Services 


Service Need In Service Name Service Description 
Code | Implementation 
Ol nex Get_Attribute All | Returns the contents of all attributes of the class. 
OE nex Conditional Get_Attribute_ Used to read a Port Class attribute value. This service is 
Single Required if any of the Port Class Attributes are supported. 
3-7.3 Port Object Instance Attributes 


The following list provides a summary of the Port Instance attributes and their associated data 
types. 
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Table 3-7.3. Port Object Instance Attributes 


Implementation | Rule Name Attribute 
Required Set | Port Type UINT 0 = connection 
terminates in this device 
1 = reserved for 
compatibility with 
existing protocols 
2 = ControlNet 
3 = ControlNet 
redundant 
4 = TCP/IP 
5 = DeviceNet 
6 — 99 = reserved for 
compatibility with 
existing protocols 
100 — 199 = Vendor 
Specific 
200 — 65534 = Reserved 
for future use 
65535 = unconfigured 
port 
Port Number | UINT CIP portnumber | Manufacturer assigns a 
associated with unique value to identify 
this port each communication 
port. Value | is reserved 
for internal product use 
(ie. backplane). 
Get Port Object | UINT Number of 16 bit | Range = 2 - 6 
words in the 
following path 
Padded Logical path The path is restricted to 
EPATH _ |segments that one logical class segment 
identify the object | and one logical instance 
which maintains |segment. The maximum 
the port. For size 1s 12 bytes. See 
example, this Appendix C, Logical 
could be the Segments. 
TCP/IP Interface 
Object. 
Get Port Name |SHORT_ | String which 
STRING | names the port. 
The maximum 
number of 
characters in the 
string is 64. For 
example, this may 
be “Port A”. 
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Need In Access Attribute | Data Type Description of Semantics 
Implementation | Rule Name Attribute 


Optional Get Port Type SHORT_ | String which 
Name STRING _|names the port 
type. The 
maximum number 
of characters in 
the string is 64. 
For example, this 
may be 
“DeviceNet”. 
Optional Port SHORT_ | String which 
Description |STRING_ |describes the port. 
The maximum 
number of 
characters in the 
string is 64. For 
example, this may 
be “Product Line 
22”, 


Required Node number of | The encoded port 
this device on number shall match the 
port. The range | value presented in 
within this data attribute 2. 
type is restricted 
to a Port Segment. 


Conditional UINT Minimum node 
number on port. 

oe 
number on port. 


Optional Electronic key of 
network/chassis 
this port is 
attached to. This 
attribute shall be 
limited to format 
4 of the Logical 
Electronic Key 
segment. 


' If a device can report its port characteristics within the range allowed (e.g. DeviceNet MACID) then it 
shall not support this attribute. Otherwise (e.g. EtherNet/IP IP Address) it shall not support this attribute. 
* A device which does not have a node number on the port can indicate a zero length node address within 
the Port Segment (0x10 0x00). 
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3-7.4 


3-7.4.1 


Release 1.0 


Port Object Instance Common Services 


The Port Object Instance supports the following CIP Common services: 


Table 3-7.4. Port Object Instance Common Services 
Service Need In Service Name Service Description 
Code Implementation 


OT nex Get_Attribute All Returns the contents of all attributes of the class. 


O5 ex 


OEnex | Conditional Get_Attribute Single | Used to read a Port Object instance attribute. This service is 
Required if any of the Port Instance Attributes are 
supported. 

10 hex Set_Attribute_ Single 

Get_Attributes_All Response 


The Get_Attributes_All response for the class attributes shall concatenate attributes 1, 2, 3, 8 
and 9 in that order. If class attribute 1 (Revision) is not supported, then a default value of one 
(1) shall be returned. The Get_Attribute_All response for the instance attributes shall 
concatenate attributes 1, 2, 3,4 and 7 in that order. 


Open DeviceNet Vendor Assoc. & ControlNet International 3-87 


Chapter 3: Communication Object Classes Volume 1: CIP Common Specification 


This page is intentionally left blank 


3-88 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification 


Chapter 4: How to Read Specifications in the 
Object Library 


Chapter 4: How to Read Specifications in the Object Library Volume 1: CIP Common Specification 


This page is intentionally left blank 


4-2 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 4: How to Read Specifications in the Object Library 


4-1 INTRODUCTION 


This chapter includes an explanation of how to read the object specifications in the library. 
Each object is defined using the same format. 


For information about Go to Section 
Reading an Object Specification 4-1 
Description of Object 4-2 
Class Code 4-3 
Attributes 4-4 
Common Services 4-5 
Object—-specific Services 4-6 
Behavior 4-7 
Connections 4-8 


Each specification contained in the library is defined based on the contents of an object. 


An object consists of the following. See Figure 4-1.1. 
e aset of closely related attributes (data) 
e aset of behaviors 
e aset of services (common or object—specific) 
e aset of connections 


Figure 4-1.1. Defining an Object Specification 


Behaviors 


Attributes 


Connections 
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4-2 


4-3 


4-4 


44.1 


4-4 


The objects in the CIP Application Object Library are defined in the following terms: 


Description a description of the object being specified 

Class Code a hexadecimal identifier assigned to each CIP object 
Attributes the data associated with this object 

Common Services a list of the common services defined for this object 


Object-specific Services | the full specifications of any services unique to this object 


Connections connections supported by this object 
Behavior the relationship between attribute values and services 
DESCRIPTION 


Every object specification begins with a brief functional definition of the object being defined. 
For example, the Description of the Identity Object reads: This object provides identification of 
and general information about the device. 


CLASS CODE 


This part of the definition is a hexadecimal value unique to an object. Use the class code to 
identify the object class when accessing objects in devices. Open DeviceNet Vendor 
Association and ControlNet International are responsible for allocation and coordination of the 
class codes. However, managing Vendor Specific class codes and guaranteeing the values are 
unique to a Vendor ID is the responsibility of individual member companies. 


In addition to the individual object definition, a summary list of all the objects and 
their class codes is located at the beginning of the Object Library. 


ATTRIBUTES 


The Attribute part of an object specification is divided into two sections: 

e Class attributes 

e Instance attributes 

e Inall cases, the term “default” indicates a “factory default” as shipped from the vendor. 


Class Attributes 


A Class Attribute is an attribute that is shared by all objects within the same class. Class 
Attributes are defined using the following terms: 


Attribute | Need in Im- | Access DeviceNet poe of Semantics eee 
ID ry Rule Name | Data 6) poe eee 


Attribute ID is an integer identification value assigned to an attribute. Use the Attribute ID in 
the Get Attributes and Set Attributes services list. The Attribute ID identifies the particular 
attribute being accessed. 
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Need in Implementation specifies whether or not the attribute is necessary in the object class 
implementation. An attribute may be Optional, Required or Conditional. 


A conditional attribute is Required if certain object behaviors and/or attributes are 
implemented as defined by the class or within the Device Profile. 


Important: If a Class Attribute is optional, then you must define a default value or a special 
case processing method for the Client to process the error message that will occur when 
accessing those objects that choose not to implement the class attribute. The “Attribute Not 
Supported” (0x14) is the required error code. 


The Access Rule specifies how a requestor can access an attribute. The definitions for access 
tules are: 
e Settable (Set) — The attribute can be accessed by one of the Set Attribute services. If 
the behavior of your device does not require a Set Attribute service, then you are not 
required to implement the attribute as settable. 


Important: Settable attributes can also be accessed by Get_Attribute services. 
e Gettable (Get) — The attribute can be accessed by one of the Get Attribute services. 


NV indicates whether an attribute value is maintained through power cycles. This column is 
used in object definitions where non-volatile storage of attribute values is required. An entry of 
‘NV’ indicates value shall be saved, ‘V’ means not saved. 


Name refers to the attribute. 


Data Type is used in the Get_ Attribute and Set_Attribute services. You must follow the 
specified data type for all products using the attribute being defined. CIP data types and their 
ranges are defined in Appendix C. 


Description of Attribute provides general information about the attribute. 


Semantics of Values specifies the meaning of the value of the attribute. 
Important: Seven Class Attribute IDs are reserved for class object definitions. They are: 
e Revision 
e Max Instance 
e Number of Instances 
e Optional Attribute list 
e Optional Service list 
e Maximum Number Class Attributes 
e Maximum Number Instance Attributes 


Because these attributes are reserved, attribute ID numbers 1 through 7 are always reserved. 
Therefore, if you want to add a class attribute to an object definition, you must start with 
attribute ID #8. Unless otherwise specified in an object definition, each class attribute 
numbered | through 7 exists as an optional attribute within each class. 


The seven reserved Class Attributes have the following definitions: 
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Table 4-4.1. Reserved Class Attributes for All Object Class Definitions 


Attribute Need in Access Name Data Type Description of Semantics of 
ID Implementation | Rule Attribute Values 


1 Conditional LH Revision 


| in _ 
3 Optional Get Number of 
Instances 


Optional Get Optional 
attribute list 
number of 
attributes 
optional 
attributes 


STRUCT of 


act, of 


Revision of this The current value 
object assigned to this 
Note: All class attribute is one 
definitions are (01). If updates 
required to include | that require an 
this class attribute. | increase in this 
value are made, 
then the value of 
this attribute 
increases by 1. 


Maximum instance | The largest 
number of an object | instance number 
currently created in | of a created 

this class level of object at this 
the device. class hierarchy 
level. 


Number of object The number of 
instances currently | object instances 
created at this class | at this class 

level of the device. | hierarchy level. 


List of optional A list of attribute 
instance attributes numbers 

utilized in an object | specifying the 
class optional attributes 
implementation. implemented in 
the device for this 
class. 


Number of The number of 
attributes in the attribute numbers 
optional attribute in the list. 

list. 


List of ee The optional 
ee numbers. attribute numbers. 
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Table 4-1.1. Reserved Class Attributes for All Object Class Definitions, continued 


Need in Access Name Data Description of Attribute Semantics of 
Implementation | Rule Type Values 


Optional Get Optional STRUCT | List of optional services A list of service 
service list utilized in an object class codes specifying 
implementation. the optional 
services 
implemented in 
the device for this 
class. 
number services Number of services in the The number of 
optional service list. service codes in 
the list. 
optional services | ARRAY | List of optional service The optional 
of UINT | codes. service codes. 


Optional Get Maximum ID The attribute ID number of 
Number Class the las t class attribute of the 
Attributes class definition implemented 

in the device. 

Optional Get Maximum ID The attribute ID number of 
Number the last instance attribute of 
Instance the class definition 
Attributes implemented in the device. 


If the value is 01, then this attribute is OPTIONAL in implementation. If the value is greater than 01, then this 
attribute is REQUIRED. 


* 


4-4.2 Instance Attributes 


An Instance Attribute is an attribute that is unique to an object instance and not shared by the 
object class. 


Instance Attributes in the Object Library are defined in the same terms as Class Attributes. 
There are no reserved Instance Attributes. 


ae ae inIm- | Access DeviceNet ee of Semantics pees 
rw Rule Name | Data © ee pees 


4-5 COMMON SERVICES 


Common Services are those whose request/response parameters and required behaviors are 
defined in Appendix A of Volume I. 


The Common Service component of an object definition includes: 


Service Pep lemeni Hen Service Name Description of Service 


@Ol@l@i_ © | @ _ 


Service Code is the hexadecimal value assigned to each CIP service. 
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4-5.1 


4-8 


2-3. Need in implementation specifies whether or not the service is needed in the 
implementation of this object at the Class level or at the Instance level. In these columns will 
appear one of three specifications: 

e Optional; or 

e Required; or 

e Not applicable (“n/a”) 


Important: If an optional service is implemented in a class, and the optional Service List 
class attribute is also implemented in the class, the service shall be included in the Service 
List. 


Services trigger the Behavior of an object based on the values of the attributes accessed by the 
service. Common Services can be directed to either the Class 

level or the Instance level of an object, which may produce different behavior 

at each level. 


e Class Level: behavior triggered by services sent to the Object Class. 
e Instance Level: behavior triggered by services sent to the Object /nstance. 


Common Services sent to Are called 
the Class Level of an object Common Class Level Services 
the Instance Level of an object Common Instance Level Services 
4. Service Name refers to the service. See Appendix A of Volume | for a complete list of 


CIP common services. 


5. Description of Service provides a brief definition of the service. 


Get_Attributes_All Response 


When the Get_Attributes_All common service is included in the list of supported common 
services, then the Get Attributes All response must be included in the object definition. This 
component specifies the sequence or order of the data returned in the Service Data portion of 
Explicit Response Message. The following byte array is an example of how the format of the 
Service Data portion of a Get_Attributes_All response is typically specified: 


0 Revision (low byte) Default = 1 

1 Revision (high byte) Default = 0 

2 Max Instance (low byte) Default = 0 

3 Max Instance (high byte) Default = 0 

4 Number of Instances (low byte) Default = 0 

5 Number of Instances (high byte) Default = 0 

6 Optional Attribute List : number of attributes (low byte) Default = 0 
if Optional Attribute List : number of attributes (high byte) Default = 0 
8 Optional Attribute List : optional attribute #1 (low byte) 

9 Optional Attribute List : optional attribute #1 (high byte) 
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4-5.2 


Release 1.0 


Optional Attribute List : optional attribute #m (low byte) 


Optional Attribute List : optional attribute #m (high byte) 


Important: Insert default values for all unsupported attributes. 


Important: If the instance attribute Number of Attributes” is not supported, the default value 
of zero is to be inserted into the response byte array and no attribute ID numbers will follow. 


Important: If the instance attribute Optional Attribute List” is not supported, the default 
value of zero is to be inserted for the ’number of attributes” and no attribute ID numbers will 
follow. 


The following rules are to be adhered to when specifying an object’s Get_Attributes_All 
response format: 

e Default values must be supplied for all ’optional” attributes. Ifa product chooses not to 
implement some of the optional attributes it will be required to insert the specified 
default value for the unimplemented attribute. 

e Ifnew attributes are added to an existing object, those attributes must be added to the 
end of the response byte array. 


Set_Attributes_All Request 


When the Set_Attributes_ All common service is included in the list of supported common 
services, then the Set Attributes All request must be included in the object definition. This 
component specifies the sequence or order of the data supplied in the Service Data portion of 
the request. The following byte array is an example of how the format of the Service Data 
portion of a Set Attributes All request is typically specified: 


At the Instance level, the order of attributes passed in the Set_Attributes_ All request is as 
follows: 
Byte Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 


0 Output Range 


1 Value Data Type 
Fault State 
Idle State 


Fault Value (high byte) 
Idle Value (low byte) 


2 
3 
4 Fault Value (low byte) 
5 
6 
7 Idle Value (high byte) 


Important: It is important to note that the Set_Attributes_AlI service can be supported by an 
object only if all settable attributes shown in the Set_Attributes_AIl request byte array are 
implemented as settable. 
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4-6 


4-10 


OBJECT-SPECIFIC SERVICES 


The section titled “Object-specific Services” provides a list of the unique services supported by 
this class of objects and their service codes. 


Whereas Common Services can be used in many objects, Object—-specific Services are unique 
to each object. 


For example, many objects support the Get_Attributes_All service; however, only the 
DeviceNet Object supports Allocate Master/Slave Connection Set (see the DeviceNet 
Standalone Specification). 


The Object-specific Services component of the object class definition includes: 


a ae in 
Service [een | Service Name Description of Service 


OI@|@| @ | © 


1. Service Code is the hexadecimal value assigned to each CIP service. 


2-3. Need in implementation specifies whether or not the service is needed in the 
implementation of this object at the Class level or at the Instance level. In these columns 
will appear one of three specifications: 

e Optional; or 
e Required; or 
e Not applicable (“n/a”) 

Important: If a service is specified to be optional and is implemented in a device, its service 

code must be included in the “optional service list” class attribute. 


Services trigger the Behavior of an object based on the values of the attributes accessed by the 
service. Object-specific Services can be directed to either the Class 
level or the Instance level of an object, which may produce different behavior 
at each level. 
e Class Level: behavior triggered by services sent to the Object Class. 


e Instance Level: behavior triggered by services sent to the Object /nstance. 


Object-specific Services sent to Are called 


the Class Level of an object Object-specific Class Level Services 


the Instance Level of an object Object—specific Instance Level Services 


4. Service Name refers to the service. 


5. Description of Service provides a brief definition of the service. 
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4-6.1 


4-6.2 
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Service Parameters 


Whereas each Common Service has fixed parameters, each Object-specific Service has unique 
parameters. This section defines those parameters for each Object—specific Service. 


Name Description of Request Semantics of Values 
Parameters 


1. Name refers to the service request parameter. 

2: Type specifies the data type of the service request parameter. 

3. Description of Request Parameters describes the purpose of the request parameter. 
4. Semantics of Values specifies the meaning of the values of the service request 


parameter, such as “the value is counts of microseconds.” 


Service Response Data 


The second table is the description of the service response data and includes: 


Description of Response 


Semantics of Values 


1. Name refers to the service response data. 

2. Type specifies the data type of the service response data. 

3. Description of Response Data describes the purpose of the response data. 
4. Semantics of Values specifies the meaning of the values of the service 


response data. 


This object definition component also includes a description of the usage and purpose of the 
service. If the service triggers a complex behavior, then you must specify it. Response Data 
from CIP Common services shall conform to that specified in Volume 1, Appendix A unless 
specified otherwise in the Object Definition or Device Profile. 


BEHAVIOR 


Behavior of an object may be triggered by an object’s services and is based on the values of the 
attributes accessed by the service. Together, the services and attribute values initiate state 
changes in the object. The behavior definition determines how an object responds when it 
receives notification of an event that changes its state. Behavior must be defined in terms of: 


the state an object is in when it receives notification of a state-changing event; and 


the event the object receives 
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State 


A State is an object’s current active mode of operation (e.,g., Running, Idle). 


To define behavior in these terms, use a State Event Matrix and a State Transition Diagram 
when applicable. A State Event Matrix is a table that lists all possible events and services that 
initiate a state change, and indicates an object’s response to the event or service based on the 
state of the object when it receives notification of that event. 


For example, the table below shows three states (other objects may or may not have other 
states): 
e Non-existent: the object has not yet been created. You must implement the create 
service to transition the object to existent. 
e Idle: the object accepts services (e.g., Start, Stop, Get_Attribute Single), but does not 
produce. 
e Running: the object is performing its function. 


Event State 

| Non-existent | tale | Running 

Create Transition to Idle Error: Object already exists. Error: Object already 

exists. 

Delete Error: Object does not __| Transition to Non-Existent Error: Object State 
exist. (General Error Conflict (General Error 
Code 0x16) Code 0x0C) 

Start Error: Object does not __| Transition to Running Error: Object State 
exist. (General Error Conflict (General Error 
Code 0x16) Code 0x0C) 

Stop Error: Object does not —_| Error: Object State Conflict Transition to Idle 


exist. (General Error 
Code 0x16) 


Get_Attribute_Single 


Error: Object does not 
exist. (General Error 
Code 0x16) 


Set_Attribute_Single Error: Object does not 
exist. (General Error 


Code 0x16) 


(General Error Code 0x0C) 


Validate/service the 
request. Return response 


Validate/service the request. 
Return response 


Validate/service the request. 
Return response 


Error: Object State 
Conflict (General Error 
Code 0x0C) 
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An event is an external stimulus that could cause a state transition. A State Transition 


Diagram graphically illustrates the state of an object and includes services and attributes that 
cause it to transition to another state. 


Get_Attribute_Single/ 
Set_Attribute_Single/ 


Non-Existent 


Delete 


Create 


Produce/Consume data, 
Get_Attributes_Single 


When applicable, some object behavior definitions include an Attribute Access Table, which 
lists all object attributes and how to access them in a given state. 


Attribute 


Number_of_Members 


Read Only Read Only 
Read Only Read Only 


Not available 


Read/Write Read Only 


Not available Read Only Read Only 


ACCESSING APPLICATION OBJECT DATA 


An Object Class definition must indicate any special provisions that have been made with 


regards to the external access of its associated data. 


As described in Chapter 1 of Volume 1,two types of Connections exist; Implicit (I/O) and 
Explicit Messaging. This section provides an overview of how these Connection types relate to 
Application Objects and how they can be used to access Application Object data. Figure 4- 
8.1. presents an overview of the relationship between the Connection Class and Application 
Objects and serves as a prefix to the overview. 


Member_List 

Data 

Owner 
Release 1.0 
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Figure 4-8.1. Connection Paths 
Object(s) 
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Assembly 
Object 


DeviceNet 
Object 


Connection Class 


4-8.1 Access Through Explicit Messaging Connections 


An Explicit Messaging Connection is capable of accessing any externally accessible object, 
including Application Objects. Explicit Messages can be used to deliver various service 
requests to Application Objects, including the reading and writing of Application Object 
attributes. 


When an Explicit Message is received, the Explicit Messaging Connection delivers the 
message information to the Message Router. The Message Router delivers the message 
information to the appropriate handler. In the case of an Explicit Request Message, the 
handler is the target object specified in the request. In the case of an Explicit Response 
Message, the handler is the Client Application that previously issued the associated request. 


4-8.2 Access Through I/O Connections 


1/O Connections contain attributes that point to or reference the Application Object(s) to which 
they deliver received data and/or from which they obtain data to transmit. 
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Figure 4-8.2. Access Paths to Application Object Data via I/O Connections 
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Application Objects can be directly referenced by an I/O Connection. This is illustrated by 
EXAMPLE 1 in Figure 4-8.2. In this example, Attribute #3 within Application Object Class 
#8/Instance #2 (Att #3) is being directly accessed by an I/O Connection. If this reference was 
made by the produced_connection_path attribute of the I/O Connection, then Att #3 data 
would be the information being produced by the I/O Connection. If this reference was made by 
the consumed_connection_path attribute of the I/O Connection, then Att #3 would be the 
recipient of the data that is consumed_by the I/O Connection. 


It is possible to access multiple attributes over a single I/O Connection. This is accomplished 
using a special Application Object called the Assembly Object. With respect to data exchange 
over an I/O Connection, an Assembly Object performs the following: 
e Assembles separate pieces of Class, Instance, and/or Attribute data together so they can 
be produced by a single I/O Connection. 
e Receives data from an I/O Connection that is associated with separate Classes, 
Instances, and/or Attributes and distributes the data accordingly. 


With this in mind, Assembly Objects provide an indirect reference to various data items. 
EXAMPLE 2 in Figure 4-8.2 illustrates an Assembly Object that groups Attributes #1 and #2 
of Class #8/Instance #2 so they can be accessed by a single I/O Connection. Note that an 
Assembly Object is capable of referencing items within more than 1 Object Class. See Chapter 
5 of Volume 1, section 5—5. for a detailed definition of the Assembly Class. 
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4-9 EXTENDING EXISTING OBJECTS AND DEFINING NEW 
OBJECTS 


If your application requires a function that existing objects do not implement, you can: 


e Add vendor-specific attributes to existing objects, or propose a 
standardized open addition to existing objects; 


e Define a new open object or a new vendor-—specific object (published 
or unpublished) to accommodate a new or revised functionality 


Use the decision table below to determine how you would like to add functionality to your 
device. 


An Object Class definition must indicate any special provisions that have been made with 
regards to the external access of its associated data. 


If you nd Then 


want to add attributes and/or services to an | you want this extension to | propose an Open Extension. 
existing object to extend its functionality, | be standardized, 


want to add attributes and/or services to an | you want to provide user— | create and publish a Vendor-specific 
existing object to extend its functionality, | access to the extension, Extension. 


want to add attributes and/or services to an | you want to keep the create, but do NOT publish 
existing object to extend its functionality, | extension proprietary, Vendor-specific Extension. 


want to create a device that has a function | you want this extension to | propose a new Open Object. 
outside the realm of existing objects, be standardized, 


want to create a device that has a function | you want to provide user— | create and publish a new Vendor-— 
outside the realm of existing objects, access to the extension, specific Object. 


want to create a device that has a function | you want to keep the new | create but do NOT publish a new 
outside the realm of existing objects, object proprietary, Vendor-specific Object. 


After determining whether you want to extend an existing object or define a new one, refer to 
the following pages for the appropriate information. 


For information about: Go to section: 
CIP Object Address Ranges 4-9.1 
Making Extensions to Objects 4-9.2 
Vendor-specific Extensions 4-9.2.1 
Open Extensions 4-9.2.2 
Defining a New Object 4-9.3 
Vendor-specific Object 4-9.3.1 
Open Object 4-9.3.2 
Defining a New Common Service 4-9.4 
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4-9.1 CIP Object Address Ranges 
Whether you decide to extend existing open objects or define new objects, you must know the 
CIP—defined Object Addressing Ranges. There are three categories: 
This range Refers to 


Open A value available to all CIP participants. Open values are defined in the CIP Common 
Specification and the associated network companion specifications. All Object Classes and 
services defined in CIP Specification fall under this category. 


Vendor- A range of values specific to the vendor of a device. These are used by vendors to extend their 

specific devices beyond the available Open options. A vendor internally manages the use of values 
within this range. Applies to object classes, attributes, and servcices. 

Object-class- A range of values whose meaning is defined by an Object Class. This range applies to Service 

specific Code definitions. 


Table 4-9.1. defines the ranges applicable to Class ID values. 
Table 4-9.1. Class ID 


Table 4-9.2. defines the ranges applicable to Attribute ID values. 
Table 4-9.2. Attribute ID Range 


Table 4-9.3. defines the ranges applicable to Service Code values. 


Table 4-9.3. Service Code Ranges 


Services. These are defined in Appendix A. 
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4-9.2 Making Extensions to Objects 


If an existing open object provides functions that closely match those of your product but do 
not completely support an implementation, then you may want to extend the existing object 
instead of creating a new object. 


You can modify the existing object to include a new behavior that would satisfy your desired 
function. A modification could entail simply adding state flags or diagnostics, or could mean 
inheriting behaviors of another existing object class in your product line. 


An extension of an existing object definition: 


e can add new attributes to the most recent definition. Deletion of attributes 
is not allowed. 


e can only add to the end of the Get_ Attributes_ All and the Set_ Attributes_ All 
structure definitions. 


e can add to the list of services. Deletions of services is not allowed. 


You can make two primary types of extensions to open objects depending on your preference 
(when making a vendor-specific extension, you can choose to publish or not): 


e vendor-—specific 
« published 
=" unpublished 
e open 
4-9.2.1 Vendor-specific Extensions 


If you want to add attributes and/or services to an existing object to extend its functionality, 
and you want only your users to have access to the extension, then 
create a vendor-specific extension. 


Important: Be sure to publish your vendor-specific extension in some way for your users. If 
you don’t publish the extension, then it is of little value because your users cannot access the 
added capability produced by the extension. 


If you want other CIP participants to standardize on your extension, then 
propose an open extension (see Section 4-9.2.2.) to the ODVA/CI organizations and 
wait for approval. 


Regardless of whether you choose to keep the extension vendor-specific or propose it as an 
open extension, the process for defining an extension is the same. 


Use the following example to examine the necessary steps for creating a vendor-specific, 
extension. 
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4-9.2.1.1 Example 


For example purposes, assume you have a Widget Object, which is an existing open object that 
has two Class attributes and three Instance Attributes. 


Class Attributes 
Number | Access Name Data Type Description of Semantics of 
Rule Attribute Values 


2 Max Instance UINT Maximum Instance 
Number 


Instance Attributes 


Number | Access Name Data Type Description of Semantics of 
Rule Attribute Values 


1 Number of USINT Number supported 
cae in this at 
2 [set | Output Value BOOL = off; 1 =on 


3 Get Status UINT Current status ——_ 
Generic Object 


This object supports these Common Services: 
e Get_Attributes_All 
e Set_Attributes_ All 


These services specify the following attributes: 


Service Attributes 
Get_Attributes All 1, 2,3 
Set_Attributes_All 2 


In addition to Common Services, the Widget Object in this example supports these Object 
Specific Services: 

e Upload Widget Attributes All 

e Download Widget Attributes All 


The current capability of the Widget Object closely matches the function of your product. 
However, it does not completely support your desired implementation. You want to extend the 
object and then publish the extension for your users. 


For example, this hypothetical device requires the instance attributes Output Value, Status, and 
Number of Attributes, but needs an additional attribute specifying /nput Value, which you 
would like to publish to your users. 


To extend the existing Widget Object to include the proprietary Input Value attribute: 
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1. Add an attribute(s): Because you can add new attributes only after the last attribute in 
the most recent definition, the Instance Attribute Input Value is assigned a value of 100. 
The new list of Instance Attributes looks like this: 


Table 4-9.4. Instance Attributes for Extended Widget Object 


Number | Access Name Data Type Description of Semantics of 
Rule Attribute Values 


1 Get Number of USINT 
attributes 
2 Output Value BOOL 


100 Set Input Value BOOL 0 = off; 1 =on 


2. Define new service structures to accommodate this new attribute: In this example, the 
access rule for the new attribute is specified as Get and Set. As a result, you need to 
specify the new structures of both services. Because you can add only to the end of the 


Get_Attributes_All and Set_Attributes_AlI structure definitions, the new service 
structures are: 


Service Attributes 
Get_Attributes_ All 1, 2, 3, 100 
Set_Attributes_All 2, 100 


3. Add to list of object specific services, if necessary. 


4. Specify the new behavior with a new version of the State Transition Diagram and 
necessary text. 


4-9.2.1.2 Implementing a Vendor-specific Extension 


Whether adding vendor-specific attributes that are published for your users or proposed as a 
standard, you must plan for differences in: 

e Revisions 

e Get All Attributes service response 

e Set All Attributes service request 


4-9.2.1.2.1 Revisions 
Every object has a Class Attribute called “Revision.” The Revision of an object specifies the 


interface to that object, which encompasses all of the items in the object specification, 
including services, attributes, connections and behavior. 


If the value of the Revision attribute is 01, then support of the Revision attribute is OPTIONAL 


in the object’s implementation. If the value is greater than 01, then support of the Revision 
attribute is REQUIRED. 
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Class Attributes 


Number | Access Name Data Type Description of Semantics of 
Rule Attribute Values 
1 Revision UINT Revision of this 
object 
2 Max Instance UINT Maximum Instance 
Number 


Important: If you extend an object in a Server device but not in a potential Client, then the 
Revision of the object in the Server device is different from the revision expected by the Client. 
As a result, the Client will not recognize the extension, and will not implement its new 
behavior. 


To remedy this situation, you must document differences between the original object definition 
and the revised object definition. You may either: 


e Update the Client; or 
e Provide for the difference in revisions by allowing the Client to process error codes 
from the Server. You can program the Client to do one of the following: 
e Report the revision mismatch with an error handler that verifies the object revision; 
or 


e Determine the revision of the Server’s object with an error handler that also 
performs special-case processing. 


Important: The Revision class attribute is not the revision of an implementation (which is 
reflected in the Identity Object, Minor/Major revision status bits), but the revision of the open 
object definition. 


If you want to specify a revision of the vendor—specific object definition, we recommend 
defining a “vendor-specific revision” class attribute in the vendor-specific address range. 


4-9.2.1.2.2 Get_Attributes_All Service Response 


When a Client is interfacing with an object, it must be prepared to accept or ignore data 
supplied for the vendor—specific extension (in addition to the specified open attributes) in a 
Get_Attributes_All response. 


4-9.2.1.2.3 Set_Attributes_All Service Response 


Processing a Set_All request for a vendor—specific object or attribute may require processing 
additional vendor-specific data than is expected by a Server. As a result, the Server object may 
process a Set_All request that lacks necessary data because the vendor-specific attributes were 
not recognized. 
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The unrecognized attributes are either critical or non-critical to the behavior of the object. 


If the unrecognized Then 
attributes are 


Critical Processing the service results in an error. Client must be 
prepared to process the error. 

Non-critical the Server processes only the open attributes and ignores the 
vendor-specific attributes (which are initialized to default 
values). 


4—9.2.2 Open Extensions 


If you want to add attributes and/or services to an existing object to extend its functionality, 
and you want this extension to be standardized, then create an open extension in the same way 
you would a vendor-specific extension. See Steps | through 4 in Section 4-9.2.1.1, Example, 
and adhere to the following exceptions: 

e Propose the use of “Open” attributes using the open ID range (00 - 63hex) instead of 


“Vendor-—specific.” 
e Submit the extension to ODVA/CI for approval 


Important: You cannot ship product based on your proposed extension until it is approved. 


49.3 Defining a New Object 


When defining a new object, either vendor—specific or open, follow these general guidelines: 


e Break large objects into smaller objects: For example, break a “Controller” into 
“Data Table”, which can be read and written, and “Program”, which can be edited. 


e Avoid multiple interdependencies: Don’t break an object into multiple objects if this 
creates many interdependencies. Keep things that are tightly coupled in one object. 


e Hide some information: Hide those aspects that are not important to the object being 
specified. For example, if you can store a set of data as an array or in a linked list, don’t 
specify one or the other. Leave the set of data as “data storage”. 


e Do not hide important semantics: Don’t hide aspects that are important to the object 
being specified. For example, don’t write a value to a special location to cause a mode 
change. Use an interface that allows you to clearly state the desired action. 


e Generalize: Ask, “If product A needs an object from product B, will it also be needed 
in product C? If this is a possibility, how can I define the object so that it is also useful 
in product C?” 


e Provide for expansion: When possible, use variable length fields. You can extend 
fields in the future to handle cases not considered today. 


Important: It is preferable to extend an existing object than to define a new one. Fewer 
larger objects are more convenient than a proliferation of smaller objects that have 
similarities. 
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In addition, use the numeric value itself instead of encoding the numeric value into a 
smaller number of bits, so that “unencodable” values become necessary in the future. 


e Be clear: Keep all statements, references and terms as clear and obvious as possible by 
using meaningful names. Don’t add complexity where not needed. 


e Make an object widely applicable: Make sure the object is useful in a wide range of 
products (i.e., from a proximity sensor to a motor starter). 


Vendor-specific 


If you want your CIP—compatible product to perform a function that existing open objects 
cannot implement, then you may define a Vendor-specific Object within the appropriate 
address ranges. See Table 4-9.5. 


Table 4-9.5. Vendor-specific Object Address Ranges 


Type Range Quantity 


Class ID 64; ex ~ CThex 100 
300hex-4FFhex ‘| 512 


AttributeID — Vendor—Specific 64nex - C7hex 100 
Service Code — Vendor-Specific 32hex - 4Ahex 25 


Service Code — Object—Specific 4Bhex - ©3hex 25 


You may choose to create a vendor—specific object for one or more of the following reasons: 
e You want to create a device that has a function outside the realm of existing objects. 
e An existing product does not fit the function of existing objects. 
e You want to create an object that has proprietary attributes and behavior. 


Defining vendor-specific objects within specified Class ID, Attribute ID, and Service Code 
values has the following advantages and disadvantages: 


Advantages Disadvantage 


Vendor controls the object The vendor must manage the dissemination of the object 


definition to other parties. 


Innovation not stifled or slowed The Client must verify that the target device is of the 
by standards process. vendor type that includes this new object definition. 


Open 


If you think a defined object and its behavior should be standardized, then propose an object 
specification with the Class Code and attribute IDs in the CIP Open address ranges to 
ODVA/CI. Also, specify common services used. See Table 4.6. 
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Table 4-9.6. Open Address Ranges 


Type Range Quantity 


Class ID 00 - 63hex 


100hex - 2FFhex 


AttributeID 00 - 63hex 


Service Code — Open 00 - 31 hex 50 


You may follow the object template used in this chapter as well as the objects defined in 


Chapter 5, CIP Object Library. This template includes: 
e Class code in open range 
e Description of the object 
e Class attributes 
e Instance attributes 
e Common services supported 
e Object-specific services supported 
e Connections 
e Behavior 


Submit the object proposal to one of the Joint Special Interest Groups (JSIGs) in ODVA/CI for 


approval. 


4-9.4 New Common Service 


If you want to define a new service that extends the current list of CIP Common Services, 


propose the service (in the open service code range) to ODVA/CI. 
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5-1. OBJECT SPECIFICATIONS 


Using the format previously defined, the objects listed in Table 5.1. are specified in this object 
library. You can also use this table as a quick reference to objects and their corresponding class 
codes. 


Table 5.1. Object Specifications in the CIP Object Library 


Code 

O3hex See the ODVA DeviceNet 
Specification 

2lhex | Analog Output Group 5-112 
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Class 
Code 


22hex 
23hex 
24hex 
2Shex 
26hex 
2Thex 
28hex 
29hex 
2Ahex 
2Bhex 
2Chex 
2Dhex 
2Ehex 
30hex 
3Thex 


32hex 


33hex 
34hex 
35hex 


FOhex 


Flhex 


F2hex 


F3hex 


Fahex 


For information about this Object: 


Analog Group 

Position Sensor Object 
Position Controller Supervisor Object 
Position Controller Object 
Block Sequencer Object 
Command Block Object 
Motor Data Object 

Control Supervisor Object 
AC/DC Drive Object 
Acknowledge Handler Object 
Overload Object 

Softstart Object 

Selection Object 

S-Device Supervisor Object 
S-Analog Sensor Object 
S-Analog Actuator Object 


S-Single Stage Controller Object 


S-Gas Calibration Object 
Trip Point Object 


ControlNet Object 


ControlNet Keeper Object 


ControlNet Scheduling Object 


Connection Configuration Object 


Port Object 
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5-118 
5-123 
5-129 
5-136 
5-146 
5-148 
5-154 
5-159 
5-167 
5-176 
5-186 
5-189 
5-195 
5-205 
5-219 
5-249 


5-256 


5-263 


5-269 


See the ControlNet 
International Specification 


See the ControlNet 
International Specification 


See the ControlNet 
International Specification 


5-276 


3-84 


Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 5: Object Library 


Class For information about this Object: Go to page: 

Code 

FShex | TCP/IP Interface Object See the EtherNet/IP 
Specification, Volume 2 


F6hex | EtherNet Link Object See the EtherNet/IP 
Specification, Volume 2 
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5-2. IDENTITY OBJECT 
Class Code: Olhex 


This object provides identification of and general information about the device. The Identity 
Object MUST be present in all CIP products. 
If autonomous components of a device exist, use multiple instances of the Identity Object. 


5-2.1. Class Attributes 


Number Need in Access Name Data Type Description of Semantics of Values 
Implementation | Rule Attribute 
This class attribute is optional and is described in Chapter 4 of this specification. 

2 Maximum instance | The largest instance 
number of an object | number of a created 
currently created in | object at this class 
this class level of hierarchy level. 
the device. 

3 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


' Tf the possibility exists that multiple subcomponents will be identified using multiple 


instances of the Identity Object, then this attribute is required to be supported. The 
numerically lowest available integer shall be assigned as the Instance Identifier of a newly 
created Identity Object Instance. 


5-2.2. INSTANCE ATTRIBUTES 


Need in 
implementation 


Access Semantics of Values 


Rule 


Data Type Description of 


Attribute 


type of product 

Required Get Product Code | UINT Identification of a See “Semantics” section 

ca particular product of 

an individual vendor 

Required Get Revision STRUCT | Revision of the item 

eo eed the Identity Object 
represents 
Get 


See “Semantics” section 


See “Semantics” section 


Fe eae 
Revision 
fev IL al 
Revision 

device 


See “Semantics” section 


Required See “Semantics” section 


6 | Required Get Serial UDINT Serial number of See “Semantics” section 
Number device 
7 | Required Get See “Semantics” section 


Product Name }|SHORT___‘| Human readable 
STRING identification 


5-6 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification 


Release 1.0 


Chapter 5: Object Library 


Need in 
implementation 
Optional 


Access 
Rule 


Optional 


Optional 


Data Type 


Configuration | UINT 
Consistency 

Value 

Heartbeat 

Interval 


Description of 
Attribute 
Present state of the 
device as represented 
by the state transition 
diagram 


Contents identify 
configuration of 
device 


The nominal interval 
between heartbeat 


Semantics of Values 


0 = Nonexistent 

1 = Device Self 
Testing 

2 = Standby 

3 = Operational 

4 = Major 
Recoverable Fault 

5 = Major 
Unrecoverable Fault 
6 — 254 = Reserved 
255 = Default for Get 
Attribute All service 


See “Semantics” section 


The default value is 0. 
Zero disables 


transmission of the 
heartbeat message. 


messages in seconds. 


The following Instance Attributes are used to identify with certainty the appropriate device 
targeted by a connection originator: 


e Vendor 

e Device Type 

e Product Code 

e Revision 

This collection of attributes, when kept by the connection originator, is often referred to as a 
device’s “electronic key”. 


Semantics: 
Vendor ID 


Vendor IDs are managed by the Open DeviceNet Vendor Association, Inc. (ODVA) and 
ControlNet International (CI). The value zero is not valid. 


Device Type 


The list of device types is managed by ODVA and CI. It is used to identify the device profile 
that a particular product is using. Device profiles define minimum requirements a device must 
implement as well as common options. 


A listing of the presently defined Device Types can be found on page 5-3. 
Product Code 


The vendor assigned Product Code identifies a particular product within a device type. Each 
vendor assigns this code to each of its products. The Product Code typically maps to one or 
more catalog/model numbers. Products shall have different codes if their configuration and/or 
runtime options are different. Such devices present a different logical view to the network. On 
the other hand for example, two products that are the same except for their color or mounting 
feet are the same logically and may share the same product code. 
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The value zero is not valid. 
Revision 


The Revision attribute, which consists of Major and Minor Revisions, identifies the Revision 
of the item the Identity Object is representing. 


The value zero is not valid for either the Major and Minor Revision fields. 


The Major and Minor Revision are typically displayed as major.minor. Minor revisions shall 
be displayed as three digits with leading zeros as necessary. The Major Revision attribute is 
limited to 7 bits. The eighth bit is reserved by CIP and must have a default value of zero. 


The major revision should be incremented by the vendor when there is a significant change to 
the ‘fit, form, or function’ of the product. Any changes that effect the configuration choices 
available to the user (and therefor the Electronic Data Sheet) require incrementing the major 
revision. 


The minor revision is typically used to identify changes in a product that do not effect user 
configuration choices. For example, bug fixes, hardware component change, labeling change, 
etc. Changes in minor revision are not used by a configuration tool to match a device with an 
Electronic Data Sheet. 


Status 


This attribute represents the current status of the entire device. Its value changes as the state of 
the device changes. The Status attribute is a WORD, with the following bit definitions: 


Table 5-2.1. Bit Definitions for Status Instance Attribute of Identity Object 


Bit (s) Called Definition 


0 Owned TRUE indicates the device (or an object within the device) has 
an owner. Within the Master/Slave paradigm the setting of this 
bit means that the Predefined Master/Slave Connection Set has 
been allocated to a master. Outside the Master/Slave paradigm 
the meaning of this bit is TBD. 


 Freserved sha be 0 


2 Configured TRUE indicates the application of the device has been 
configured to do something different than the ““out—of—box”’ 
default. This shall not include configuration of the 
communications. 


ee 


4-7 Extended Device Status Vendor-specific or as defined by table below. The EDS shall 
indicate if the device follows the public definition for these bits. 
8 Minor Recoverable Fault | TRUE indicates the device detected a problem with itself, which 
is thought to be recoverable. The problem does not cause the 
device to go into one of the faulted states. See Behavior section. 


9 Minor Unrecoverable TRUE indicates the device detected a problem with itself, which 
Fault is thought to be unrecoverable. The problem does not cause the 

device to go into one of the faulted states. See Behavior section. 

10 Major Recoverable Fault | TRUE indicates the device detected a problem with itself, which 


caused the device to go into the “Major Recoverable Fault” 
state. See Behavior section. 
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Bit (s) Called Definition 


11 


Major Unrecoverable TRUE indicates the device detected a problem with itself, which 
Fault caused the device to go into the “Major Unrecoverable Fault” 
state. See Behavior section. 


12-15 Reserved, shall be 0 


Table 5-2.2. Bit Definitions for Extended Device Status Field 


Bits 4-7: Extended Device Status Description 
000 0 Self-Testing or Unknown 
000 1 Firmware Update in Progress 
001 0 At least one faulted I/O connection 
0011 No I/O connections established 
010 0 Non-Volatile Configuration bad 
0101 Major Fault — either bit 10 or bit 11 is true (1) 
O11 0 At least one I/O connection in run mode 
O1li1ii1 At least one I/O connection established, all in idle mode 
100 0 Reserved, shall be 0 
MQ: src: 
1010 Vendor/Product specific 
thru 
1ii1iti 


The values of the following Status bits indicate the state of the device: 


Bit 8: Minor Recoverable Fault 
Bit 9: Minor Unrecoverable Fault 
Bit 10: Major Recoverable Fault 
Bit 11: Major Unrecoverable Fault 


Note that the events that constitute a fault (recoverable or unrecoverable) are to be determined 
by the product developer. The following examples should help to define the various types of 
faults: 


Minor Recoverable Fault - an analog input device is sensing an input that exceeds the 
configured maximum input value 

Minor Unrecoverable Fault - the device’s battery backed RAM requires a battery 
replacement. The device will continue to function properly until the first time power is 
cycled. 

Major Recoverable Fault - the device’s configuration is incorrect or incomplete 

Major Unrecoverable Fault - the device failed its ROM checksum process. 


Minor (no state change) 


Recoverable | Non—recoverable 


Bit 9 


Major (state changes) Bit 10 Bit 11 


The event that sets the bit also causes a state change. See the State Transition Diagram in 
Figure 5-2.3. 


Serial Number: 
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This attribute is a number used in conjunction with the Vendor ID to form a unique identifier 
for each device on any CIP network. Each vendor is responsible for guaranteeing the 
uniqueness of the serial number across all of its devices. 


Product Name: 


This text string should represent a short description of the product/product family represented 
by the product code in attribute 3. The same product code may have a variety of product name 
strings. The maximum number of characters in this string is 32. 


State: 


This attribute is an indication of the present state of the device. Note that the nature of a Major 
Unrecoverable Fault could be such that it may not be accurately reflected by the State attribute. 


Configuration Consistency Value: 


A product may automatically modify the Configuration Consistency Value whenever any non- 
volatile attribute is altered. A client node may, or may not, compare this value to a value 
within its own memory prior to system operation. The client node’s behavior, upon detection 
of a mismatch, is vendor specific. The Configuration Consistency Value may be a CRC, 
incrementing count or any other mechanism. The only requirement is that if the configuration 
changes, the Configuration Consistency Value shall be different to reflect the change. 


Heartbeat Interval: 


This attribute sets the nominal interval between production of optional heartbeat messages. 
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Common Services 


The Identity Object provides the following Common Services: 


Service 
Code 


Need in Implementation Description of Service 


Service Name 
Class Instance 


Conditional” | Get_Attribute Single 


Optional Conditional” Get_Attributes_All 


Returns the contents of the 
specified attribute. 
Optional Invokes the Reset service 
for the device. 


Returns a predefined listing 
of this objects attributes 

(See the Get_Attributes_All 
Response definition below) 


n/a Conditional | Set_Attribute_Single Modifies an attribute 
(Required if Heartbeat 
interval is defined) 


10hex 


Optional Find_Next_Object_Instance | Causes the specified Class 
to search for and return a 
list of instance IDs of 
existing instances of the 
Identity object. 


'The Get_Attribute_Single service is REQUIRED if any Class attributes are implemented. 


"Either the Get_Attribute_Single or the Get_Attributes_All service shall be supported at a 
minimum. 


Reset Service 

When the Identity Object receives a Reset request, it: 

e determines if it can provide the type of reset requested 

e responds to the request 

e attempts to perform the type of reset requested 

The Reset common service has the following object-specific parameter: 


Name Type Description of Request Semantics of 
Parameters Values 
Type USINT Type of Reset See Table 
below. 


Open DeviceNet Vendor Assoc. & ControlNet International 5-11 


Chapter 5: Object Library Volume 1: CIP Common Specification 


The parameter Type for the Reset common service has the following bit specifications: 


Type of Reset: 


Emulate as closely as possible cycling power on the item the Jdentity 
Object represents. This value is the default if this parameter is omitted. 


1 Return as closely as possible to the out-of-box configuration, then 
emulate cycling power as closely as possible. 


5-2.3.2. Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes All response is as follows: 


Byte Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
0 Revision (low byte) Default = 1 
1 Revision (high byte) Default = 0 


Max Instance (low byte) Default = 1 

Max Instance (high byte) Default = 0 

Max ID Number of Class Attributes (low byte) Default = 0 
Max ID Number of Class Attributes (high byte) Default = 0 
Max ID Number of Instance Attributes (low byte) Default = 0 


NY ITD [OW JR JW TN 


Max ID Number of Instance Attributes (high byte) Default = 0 


Important: Insert default values for all unsupported attributes. 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes_All response is as follows: 


Byte Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
Vendor (low byte) 
Vendor (high byte) 
Device Type (low byte) 
Device Type (high byte) 
Product Code (low byte) 
Product Code (high byte) 


Major Revision 
Minor Revision 


Status (low byte) 


Oo 1O IN ID J HIPRI[ WIL NTR |o 


Status (high byte) 

10 Serial Number (low byte) 
11 Serial Number 

12 Serial Number 

13 Serial Number (high byte) 
14 Product Name length 
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Byte Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 


15 Product Name (Ist character) 

16 Product Name (2nd character) 

n Product Name (last character) 

n+] State, Default = 255 

n+2 Configuration Consistency Value, Default = 0 
n+4 Heartbeat Interval, Default = 0 


Important: Insert default values for all unsupported attributes. 


Important: Because the length of the name is not known before issuing the Get_Attributes_All 
service request, allow enough memory space to store a response up to 32 characters in length. 


Object-specific Services 
The Identity Object provides no Object—specific services. 


Behavior 

The behavior of the Identity Object is illustrated in the State Transition Diagram (STD) in 
Figure 52.3. This STD associates the state of the device with the status reported by the Status 
Attribute with the state of the Module Status LED. 


Important: A device may not be able to communicate in the Major Unrecoverable Fault state. 
Therefore, it might not be able to report a Major Unrecoverable Fault. It will not process a 
Reset service. The only exit from a Major Unrecoverable Fault is to cycle power. 


The Identity object triggers production of heartbeat messages as defined by the underlying 
network when: 


e the interval configured in the Heartbeat Interval Attribute has passed since the last 
heartbeat message. 

e the Heartbeat message contents change, at a maximum rate of one “data changed” heartbeat 
message per second. 


The Heartbeat Interval value shall be saved as a Non-Volatile attribute. Heartbeat messages are 
only triggered after the device has successfully completed the network access state machine 
and is online. Not all networks support sending the Heartbeat message. 
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Figure 5-2.3. State Transition Diagram for Identity Object 
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y Heartbeat production enabled (if device is able to communicate) 
The STD for the Identity object contains the following events: 


e Power Applied - the device is powered up 

e Passed Tests - the device has successfully passed all self tests 

e Activated - the device’s configuration is valid and the application for which the device was 
designed is now capable of executing (communications channels may or may not yet be 
established) 

e Deactivated - the device’s configuration is no longer valid and the application for which 
the device was designed is no longer capable of executing (communication channels may 
or may not still be established) 

e Minor fault - a fault classified as either a minor unrecoverable fault or a minor recoverable 
fault has occurred 

e Major recoverable fault - an event classified as Major Recoverable Fault has occurred 

e Major unrecoverable fault - an event classified as a Major Unrecoverable Fault has 
occurred 
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Event Nonexistent Device Self Standby Operational Major Major 
Testing Unrecoverable | Recoverable 
Fault Fault 
Power Loss Not Transition to Transition to Transition to Transition to Transition to 
Applicable Nonexistent Nonexistent Nonexistent Nonexistent Nonexistent 
Power Applied | Transition to Not Not Not Not Not 
Device Self Applicable Applicable Applicable 
Testing 
Failed Tests Not Transition to Not Not Not 
Applicable Major Applicable Applicable Applicable 


Unrecoverable 
Fault 


Passed Tests Not Transition to Not Not Not Not 
Applicable Standby Applicable Applicable Applicable Applicable 

Deactivated Not Ignore Event Ignore Event Transition to Ignore Event | Ignore Event 
Applicable Standby 


Activated Not Ignore Event Transition to Ignore Event Ignore Event | Ignore Event 
Applicable Operational 
Major Not Not Transition to Transition to Ignore Event | Ignore Event 
Recoverable Applicable Applicable Major Major 
Fault Recoverable Recoverable 
Fault Fault 
Major Not Not Transition to Transition to Ignore Event | Ignore Event 
Unrecoverable | Applicable Applicable Major Major 
Fault Unrecoverable | Unrecoverable 
Fault Fault 
Minor Not Ignore Event Ignore Event Ignore Event Ignore Event Ignore Event 
Recoverable Applicable 
Fault 
Minor Not Ignore Event Ignore Event Ignore Event Ignore Event Ignore Event 
Unrecoverable | Applicable 
Fault 
Fault Not Not Not Not Not Transition to 
Corrected Applicable Applicable Applicable Applicable Applicable Standby 
Reset Not Restart Self Tests | Transition to Transition to Ignore Event | Transition to 
Applicable Device Self Device Self Device Self 
Testing Testing Testing 
Module Off Flashing Flashing Green | Solid Green Solid Red Flashing Red 
Status LED Red/Green 


The SEM for the Identity object contains the following states: 


e Nonexistent - the device is without power 

e Device Self Testing - the device is executing its self tests 

e Standby - the device needs commissioning due to an incorrect or incomplete configuration 

e Operational - the device is operating in a fashion that is normal for the device 

e Major Recoverable Fault - the device has experienced a fault that is believed to be 
recoverable 

e Major Unrecoverable Fault - the device has experienced a fault that is believed to be 
unrecoverable 
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5-3. MESSAGE ROUTER OBJECT 
Class Code: 02hex 


The Message Router Object provides a messaging connection point through which a Client 
may address a service to any object class or instance residing in the physical device. 


5-3.1. Class Attributes 


Need in Access Name Data Type | _ Description of 
Implementation | Rule Attribute 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Number Semantics of Values 


5-3.2. Instance Attributes 


implementation | Rule Attribute 
1 Optional Get Object_list STRUCT |A list of supported | Structure with an array 
of objects of object class codes 
supported by the 
device 
Number UINT Number of The number of class 
supported classes __| codes in the classes 
in the classes array | array 
Classes ARRAY of | List of supported __| The class codes 
UINT class codes supported by the 
device 
2 Optional Get Number UINT Maximum number | Count of the max 
Available of connections number of connections 
supported supported 
3 Optional Get Number UINT Number of Current count of the 
active connections number of connections 
currently used by _} allocated to system 
system components | communication 
4 Optional Get Active ARRAY A list of the Atray of system 
Connections | of: UINT connection IDs of | connection IDs 
the currently active 
connections 


5-3.3. Common Services 


The Message Router Object provides the following Common Services: 


Service Need in Implementation Service Name Description of Service 


Code 


specified attribute. 
Olnex Returns the contents of all 
attributes 


*The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 
5-3.3.1. | Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply data” 
portion of the Get_Attributes_All response is as follows: 
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0 Revision (low byte) Default = 1 
1 Revision (high byte) Default = 0 
2 Optional Attribute List : number of attributes (low byte) Default = 0 
3 Optional Attribute List : number of attributes (high byte) Default = 0 
4 Optional Attribute List : optional attribute #1 (low byte) 
2 Optional Attribute List : optional attribute #1 (high byte) 
n Optional Attribute List : optional attribute #m (low byte) 
n+1 Optional Attribute List : optional attribute #m (high byte) 


Optional Service List : number of services (low byte) Default = 0 
Optional Service List : number of services (high byte) Default = 0 


Optional Service List : optional service #1 (low byte) 


Optional Service List : optional service #m (low byte) 
Optional Service List : optional service #m (high byte) 
Max ID Number of Class Attributes (low byte) Default = 0 
Max ID Number of Class Attributes (high byte) Default = 0 
Max ID Number of Instance Attributes (low byte) Default = 0 
Max ID Number of Instance Attributes (high byte) Default = 0 


Important: If the class attribute Optional Attribute List” is not supported, the default value of 
zero is to be inserted into the response byte array and no optional attribute numbers will follow. 


Important: If the class attribute ’Optional Service List” is not supported, the default value of 
zero 1s to be inserted into the response byte array and no optional service numbers will follow. 


Important: Insert default values for all unsupported attributes. 
At the Instance level, the order of the attributes returned in the “Object/service specific reply 


data” portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Get Attributes All response is as follows: 


Object_list : Number (low byte) Default = 0 


1 Object_list : Number (high byte) Default = 0 
2 Object_list : Class #1 (low byte) 
3 Object_list : Class #1 (high byte) 
n Object_list : Class #m (low byte) 
n+1 Object_list : Class #m (high byte) 


Number Available (low byte) Default = 0 
Number Available (high byte) Default = 0 


Number active (low byte) Default = 0 
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Number active (high byte) Default = 0 


Active Connections #1 (low byte) 


Active Connections #1 (high byte) 


Active Connections #m (low byte) 


Active Connections #m (high byte) 


Important: Insert default values for all unsupported attributes. 


Important: If the Instance attribute ”Object_list” is not supported, the default value of zero is 
to be inserted into the response byte array and no Object_list class numbers will follow. 


Important: If the Instance attribute *’Number active” is not supported, the default value of zero 
is to be inserted into the response byte array and no Active Connection numbers will follow. 


Important: Insert default values in place of unsupported attributes. 


Object-Specific Services 

The Message Router Object provides no Object-specific services. 

Behavior 

The Message Router Object receives explicit messages and performs the following functions: 


e interprets the Class Instance specified in a message 
e routes a service to the specified object 

e interprets services directed to it 

e routes a response to the correct service source 


Service Request 


Interpretation of the Class Instance is performed on every service received by the Message 
Router. 


Any Class Instance that cannot be interpreted by a device’s implementation of a Message 
Router will report the Object_Not Found error. 


The service is then routed to a target object. 


Service Response 


All service responses are routed to the Explicit Messaging connection across which the service 
request was received. 
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5-4. DEVICENET OBJECT 
Class Code: 03hex 


The DeviceNet Object provides the configuration and status of a DeviceNet port. Each 
DeviceNet product must support one (and only one) DeviceNet object per physical connection 
to the DeviceNet communication link. 


See the DeviceNet standalone specification for the definition of this object class. 


5-20 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 5: Object Library 


5-5. ASSEMBLY OBJECT 
Class Code: 04hex 


The Assembly Object binds attributes of multiple objects, which allows data to or from each 
object to be sent or received over a single connection. Assembly objects can be used to bind 
input data or output data. The terms input” and ”output” are defined from the network’s point 
of view. An input will produce data on the network and an output will consume data from the 
network. 


Revision History 


Connection Description 
Class Revision 
00 Pre-release definition 
01 Initial release 
02 1. Class specific Service Codes 4By.-, and 4Cy¢x obsoleted 


Assembly objects instances can either be dynamic or static: 


e Dynamic: assemblies with member lists created and managed by the user. The member list 
can be altered by adding or deleting members. Dynamic assemblies shall be assigned 
instance Ids in the vendor specific range. 

e Static: assemblies with member lists defined by the device profile or by the manufacturer 
of the product. The Instance number, number of members, and member list are fixed. Static 
assemblies can usually be implemented entirely in ROM. 


Important: Instances of the Assembly Object are divided into the following address ranges to 
provide for extensions to device profiles. 


Table 5-5.1. Assembly Instance ID Ranges 
Range Meaning Quantity 
01 - 63nex Open (static assemblies defined in device profile) 99 


64hex - C7hex Vendor Specific static assemblies and dynamic 100 
assemblies 


C8hex - FFhex Reserved by CIP for future use 56 
100hex - 2FFhex Open (static assemblies defined in device profile) 512 


300hex - 4FFhex Vendor Specific static assemblies and dynamic 512 
assemblies 


500hex - FFFFhex | Reserved by CIP for future use 64,256 
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5-5.1. Class Attributes 


Attribute Need in Access Name Data Type | Description of | Semantics of Values 
Implementation Rule Attribute 


ID 
Conditional* Get Revision UINT Revision of The current value 
this object assigned to this 
attribute is two (02). 


2 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 
*This attribute is REQUIRED if Instance Attribute 2 is supported, otherwise this attribute is OPTIONAL. 


5-5.2. Instance Attributes 


Attribute Need in Access Name Data Type | Description of | Semantics of Values 
ID Implementation Rule Attribute 


Conditional Get Number of UINT Required for 
Members in Dynamic Assembly 
List only 
2 Conditional Set for Member List ARRAY of | The member Required for 
Dynamic/ STRUCT: list is an array | Dynamic Assembly 
Get for of CIP paths only 
Static 


Member Data | UINT Size of Size in bits 
Description member data. 


Member Path Size of 
Size Member Path 


(in bytes). 


Member Path | Packed See Appendix 
EPATH C for the 
format of this 
field. 


Data ARRAY of 
BYTE 


The Assembly Object provides the following Common Services: 


| 


5-5.3. Common Services 


Service Need in Implementation Service Name Description of Service 


Code 
Static | Static Assembly _| Dynamic Assembly 


OEnex Conditional! Required Required Required Get_Attribute_ | Returns the contents of the 
Single specified attribute. 


O8hex Required [n/a Create Instantiates an Assembly 
Object within a specified 
class. Response contains 
instance number. Dynamic 
assemblies shall be assigned 
instance Ids in the vendor 
specific range. 


Single 
Optional" Required Delete Deletes an Assembly Object 
and releases all associated 
resources. 
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Service Need in Implementation Service Name Description of Service 


Code 
Static Assembly Dynamic Assembly 


n/a n/a Conditional’ | Insert_ Adds a member to the 
Member Assembly Member List. 
n/a n/a Conditional*t |Remove_ Removes a member from the 
Member Assembly Member List. 
| 
/a /a 


1Ahex 
1Bhex 


18hex 


Optional Optional Get_Member | Returns a member from the 
Assembly Member List. 

n n Optional Set_ Member | Modifies a member of the 
Assembly Member List. 


19hex 


!Required if Max Instance is implemented or Instance Attribute 2 (Member List). 


21¢ you choose NOT to support the Set_Attribute_Single common service at the Instance level for a Dynamic 
Assembly, then your product shall support the Insert_ Member and Remove Member common services. 


3 At the class level this service deletes all existing Assembly instances. 


4i¢ you choose NOT to support the Insert_Member and Remove_Member common services at the Instance level 
for a Dynamic Assembly, then your product shall support the Set_Attribute_Single common service. 


5-5.4. Object-specific Services 


The Assembly Object provides no Object—specific services. The following Object-specific 
service codes have been obsoleted: 


Obsoleted Service Name Description of Service 
Service 


Code 


Need in Implementation 


Static Assembly Dynamic Assembly 


/a n/a n/a n/a 


5-5.5. Behavior 


The behavior of the Assembly Object differs by the type of Assembly: dynamic or static. A 
Dynamic Assembly’s member list is created and managed by the user of the device. The 
manager of the dynamic assembly must specify and maintain the member list. 


Obsolete 


Remove_Member | Obsolete 


4Bhex 


A Static Assembly’s member list is defined by the device manufacturer. It cannot be modified. 


To provide for the ability to create and delete objects, as well as change member lists, Dynamic 
Assemblies support additional services which are not supported by Static Assemblies. 


The following rules apply to the member lists of both static and dynamic assemblies. 
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When an empty path (Member Path Size = 0) is used in an assembly member list, the assembly 
inserts/discards the number of bits as specified in the Member Data Size field when 
producing/consuming. The assembly shall use a value of zero for all produced data which has 
been inserted. The use of an empty consumed path allows, for example, data destined for 
multiple nodes to be sent in a single message since each node can be configured to discard data 
in the message not intended for it. 


The empty path shall be supported for all dynamic assemblies. 


No checking is done by the Assembly Object at any time to verify that the size of the member 
data is correct for the given member path. It is the responsibility of the assembly member to 
properly handle too much or too little data. The assembly is required to deliver the configured 
number of bits to the member. 


No padding is done by the Assembly Object to align data from each assembly member on a 
byte, word, or other boundary. 


5-5.5.1. Static Assemblies 


The following State Transition Diagram, State Event Matrix and Attribute Access Table 
illustrate the behavior of Static assemblies. 
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Event Static Assembly Object State 


Power Up Not applicable Not applicable 


Get_Attribute | Error: Object does not exist. | Validate/service the request | Validate/service the request 
_ Single (General Error Code 16,¢x) | Return response Return response 


Set_Attribute | Error: Object does not exist. | Validate/service the request | Error: Object State Conflict 


_ Single (General Error Code 16,¢x) | Return response (General Error Code 0Ch ex) 
Message Error: Object does not exist. | Begin producing/consuming | Error: Object State Conflict 
produced/ (General Error Code 16,¢x) | from/to each member in list | (General Error Code 0Cpe¢x) 
consumed Transition to Active 

End of Error: Object does not exist. | Error: Object State Conflict | Transition to Inactive 
production/ (General Error Code 16p,¢,) | (General Error Code 0Chex) 

consumption 


Table 5-5.2. Static Assembly Object Attribute Access 


Attribute Static Assembly Object State 


Number_of Members | Not available Read Only Read Only 
Member_List Not available Read Only Read Only 


Data Not available Read/Write Read Only 


5-5.5.2.. | Dynamic Assemblies 


The State Transition Diagram, State Event Matrix and Attribute Access Table below illustrate 
the behavior of Dynamic assemblies. 
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Dynamic Assembly Object State 


Non-Existent 


Class instantiates an Assembly 
Object. Transition to Inactive 


Error: Object does not exist. 
(General Error Code 0x16) 


Error: Object does not exist. 
(General Error Code 0x16) 


Error: Object does not exist. 
(General Error Code 0x16) 


Error: Object does not exist. 
(General Error Code 0x16) 


Error: Object does not exist. 
(General Error Code 0x16) 


Error: Object does not exist. 
(General Error Code 0x16) 


Error: Object does not exist. 
(General Error Code 0x16) 


Active 


Not applicable Not applicable 


Release all associated Error: Object State 
resources. Transition to Conflict (General Error 
Non-Existent Code 0x0C) 


Validate/service the Validate/service the 
request. Return response request. Return response 
Validate/service the Error: Object State 


request. Return response Conflict (General Error 
Code 0x0C) 
Validate/service the Error: Object State 
request. Return response Conflict (General Error 
Code 0x0C) 
Validate/service the Error: Object State 


request. Return response Conflict (General Error 
Code 0x0C) 


Begin Error: Object State 
producing/consuming Conflict (General Error 
from/to each member in Code 0x0C) 

list. Transition to Active. 


Error: Object State Conflict | Transition to Inactive 
(General Error Code 0x0C) 
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Table 5-5.3. Dynamic Assembly Object Attribute Access 
Attribute Dynamic Assembly Object State 


Number_of Members | Not available Read Only Read Only 


Member List! Not available Read/Write Read Only 
Data Not available Read/Write Read Only 


! This attribute can be set by either the Insert_Member service (one member at a time) or 
the Set_Attribute Single service (all members at once). 


5-5.5.3. Connection Points 


Connection Points within the Assembly Object are identical to Instances. For example, 
Connection Point 4 of the Assembly Object is the same as Instance 4. Specifying an EPATH 
of “20 04 24 VV 30 03” is the same as “20 04 2C VV 30 03”. 
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5-6. CONNECTION OBJECT 
Class Code: O5hex 


Use the Connection Object to manage the characteristics of a communication connection. 


See Chapter 3 for the definition of this object class. 


5-28 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 5: Object Library 


5-7. CONNECTION MANAGER 
Class Code: 06hex 


Use this object for connection and connectionless communications, including establishing 
connections across multiple subnets. 


See Chapter 3 for the definition of this object class. 
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5-8. REGISTER OBJECT 
Class Code: 07hex 


Use this object to address individual bits or a range of bits up to 64K bits of data. 
Note that a Register object can operate as either an input register or an output register. The 


terms “input” and “output” are defined from the network’s point of view. An input will 
produce data on the network and an output will consume data from the network. 


5-8.1. Class Attributes 


Attribute Need in Access Rule | Name Data Description of | Semantics of 
ID Implementation Type Attribute Values 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


5-8.2. Instance Attributes 
Attribute Need in Access Rule Name Data Description of | Semantics of 
ID implementation Type Attribute Values 


1 Required Get Bad Flag |BOOL 0=good 
1=bad 
2 Required Set Direction |BOOL Direction of 0=Input Register, 
data transfer 1=Output 
Register 
3 Required Set Size UINT Size of register 
data in bits 
4 Required Set (Set is Data ARRAY _ | Data to be * 
optional if of BITS | transferred 
Direction=1) 


* All encoded bits are to be LSB aligned. See the encoding example below. 


30 bit array encoding example 
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Common Services 


The Register Object provides the following Common Services: 
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Service 
Code 


Need in 
Implementation 


Get_Attribute_Single 
Set_Attribute_Single 


Service Name 


Description of Service 


Returns the contents of the 
specified attribute. 


Modifies an attribute value. 


*The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 


Object-—specific Services 


The Register Object provides no Object-specific services. 


Behavior 


Get_Attribute_Single/ 
Set_Attribute_Single 


= 


Power Up 


The State Transition Diagram, State Event Matrix, and Attribute Access Table below illustrate 
the behavior of the Register Object. 
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Power up 
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Transition to Run 


Error: Object does not 
exist (General Error 


Code 16p¢x) 


Error: Object does not 
exist (General Error 
Code 16hex) 


Error: Object does not 
exist (General Error 
Code 16p¢x) 


State 
Run 
Not applicable. 


Validate/service the request. 
Return response. 


Validate/service the request. 
Return response. 


Apply/retrieve data. 
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5-9. DISCRETE INPUT POINT OBJECT 
Class Code: O08hex 


The Discrete Input Point (DIP) Object models discrete inputs in a product. You can use this 
object in applications as simple as a toggle switch or as complex as a discrete I/O control 
module. Note that the term ”input” is defined from the network’s point of view. An input will 
produce data on the network. 


The Discrete Input Point interface is to real input points such as a switch or screw terminal. 
The input is sampled and the data is stored in this object’s VALUE attribute. A sample of the 
discrete input value is triggered via an external command (input change-of-state, cyclic data 
trigger, etc.) 


5-9.1. Revision History 


Since the initial release of this object class definition changes have been made that require a 
revision update of this object class. The table below represents the revision history: 


Revision Reason for object definition update 
01 Initial Definition at First Release of Specification 
02 IDLE state removed from this object’s behavior 


5-9.2. Class Attributes 


Attribute Need in Access Name Data Type | Description of Semantics of 
ID Implementation | Rule Attribute Values 


1 Required Get Revision UINT Revision of this | The current 
object value assigned 
to this attribute 

is two (02). 


2 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 
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5-9.3. Instance Attributes 
Attribute Need in Access Name Data Type | Description of Semantics of 
ID implementation | Rule Attribute Values 


1 Optional Get Number of Number 
Attributes supported in this 
product 
2 Optional Get Attribute List | ARRAY List of attributes 
OF USINT | supported in this 
product 
3 Required Get Value BOOL Input point O=off,; 
value 1=on 
4 Optional Get Status BOOL Input point 0=OK; 
status 1=product 
specific alarm or 
status 
5 Optional Set Off On Delay | UINT filter time for off | The default 
to on transition | value is 0. 
0 - 65,535 
microseconds ! 
6 Optional Set On Off Delay | UINT filter time for on | The default 
to off transition | value is 0. 
0 - 65,535 
microseconds 2 


'The input must be on for the amount of filter time specified by the OFF_ON DELAY attribute before the 
ON state is recorded in the VALUE attribute. 

2The input must be off for the amount of filter time specified by the ON_OFF DELAY attribute before the 
OFF state is recorded in the VALUE attribute. 


5-9.4. Common Services 


The Discrete Input Point Object provides the following Common Services: 


Service Need in Service Name Description of Service 
Code Implementation 


OEpex |Required | Required |Get_Attribute_Single | Returns the contents of the specified 
attribute. 

Olnex | Optional | Optional | Get_Attributes_All Returns a predefined listing of this objects 
attributes (See the Get_Attributes_ All 
Response definition below) 


10hex Set_Attribute_Single Modifies an attribute value. 


O2hex | Optional | Optional | Set_Attributes_All Modifies the value of a list of attributes (See 
the Set_Attributes_All Request definition 
below) 


See Appendix A for definitions of these common services. 
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5-9.4.1. | Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply data 
portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 


” 


Byte Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
0 Revision (low byte) 
1 Revision (high byte) Default = 0 
2 Max Instance (low byte) Default = 0 
3 Max Instance (high byte) Default = 0 
4 Max ID Number of Class Attributes (low byte) Default = 1 
5 Max ID Number of Class Attributes (high byte) Default = 0 
6 Max ID Number of Instance Attributes (low byte) Default = 3 
7 Max ID Number of Instance Attributes (high byte) Default = 0 


Important: Insert default values for all unsupported attributes. At the Instance level, the order 
of the attributes returned in the “Object/service specific reply data” portion of the 
Get Attributes All response is as follows: 


Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 


Number of Attributes Default = 0 


1 Attribute List (attribute #1) 


Attribute List (attribute #m) 


Status 
Default = 
0 


Off On Delay (low byte) Default = 0 


Off On Delay (high byte) Default = 0 


On_Off Delay (low byte) Default = 0 


On_Off Delay (high byte) Default = 0 


Important: Insert default values for all unsupported attributes. 


Important: If the instance attribute Number of Attributes” is not supported, the default value 
of zero is to be inserted in its place and no members of the ’Attribute List” attribute will 
follow. 


5-9.4.2. Set_Attributes_All Request 
No settable attributes currently exist at the Class level for the Discrete Input Point Object. 


At the Instance level, the order of attributes passed in the Set_Attributes All request is as 
follows: 
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5-9.5. 


5-9.6. 


Release 1.0 


Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
Off _On Delay (low byte) 
Off _On Delay (high byte) 
On_Off Delay (low byte) 
On_ Off Delay (high byte) 


Important: The Set_Attributes_All service is to be supported only if all settable attributes 
shown above are implemented as settable. 

Object-specific Services 

The DIP Object provides no Object-specific services. 


Behavior 


The State Transition Diagram in Figure 5-9.1. provides a graphical description of the events 
and corresponding state transitions. A subset of the states and events may be supported in an 
application, but the behavior must be consistent. 


The State Event Matrix in Table 5-9.2. lists all pertinent events and the corresponding action to 
be taken while in each state. 


Important: Events can occur simultaneously, but the Fault events have priority if they occur 
simultaneously with other events. 
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Figure 5-9.1. State Transition Diagram for Discrete Input Point Object 


C) Non-Existent ‘Power Down 


Power Up 
LED Off 


@) Available 


Connection Deleted 
(from any state) Apply_ Attributes | 


LED Off 


Get/Set_Attributes 


Unrecoverable 
Fault detected’ 


Connection Transitions (from any state) 


to Established 
LED Solid Green G) LED Solid Red 
Unrecoverable 
Fault 
Sample 
Trigger 


Fault Cleared 


LED Solid Green @) Recoverable 
a Fault 


RecoverableFault detected1 
or Connection Transitions to 
Timed-Out 


LED Flash Red 


Get/Set_Attributes Get/Set_Attributes 


‘Indicated by the application 
LED = I/O Status LED 


Important: Events can occur simultaneously, but the Fault events have priority if they occur 
simultaneously with other events. 


The following SEM contains these states: 


e = Non-Existent: a module without power. 

e Available: waiting for a connection, power—up discrete input point defaults are set. 
e Run: DIP sensing data from its input and transmitting the data. 

e Recoverable Fault: a recoverable fault has occurred. 

e Unrecoverable Fault: an unrecoverable fault has occurred. 


The SEM also contains these events: 


This event Is 
Sample Trigger a change of state, cyclic timer trigger, application trigger 
Connection Deleted 1/O connection deleted. 
Apply_Attributes the Apply service of the I/O connection object the Discrete Input Point object is 


connected to. Note: the application is responsible for validating the connection 
object’s attributes. 


Fault Cleared the application clearing a detected fault 
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This event Is 
Connection Transitions I/O connection transitions to Established. 
to Established 
Connection Transitions I/O connection transitions to Timed-Out 


to Timed Out state 


The figure below is a conceptual illustration of the state machine for a typical input object 
(producing application). The events listed above are represented by the dotted line labeled 
“state change.” 


I/O Message 


2 V/O data 
Explicit conus Input Object 
2 Messages yee Producer Instance 


' Get_Attributes 
: Set_Attributes 
1 Apply_Attributes ; 


Request Message 
Validation 


Table 5-9.2. State Event Matrix for the Discrete Input Point Object 


Event State 


Non-Existent Available Recoverable | Unrecoverable 
Fault Fault 
Sample Trigger Not Applicable Ignore event Sample data, | Ignore event | Ignore event 
Send data 


Apply Attributes Not Applicable | Verify attributes, | Return error Return error Ignore event 
return result (Object State | (Object State 
Conflict) Conflict) 


Connection Not Applicable Ignore Event Transition to | Transitionto | Ignore event 
Deleted Available Available 

Connection Not Applicable Transition to Ignore event | Ignore event | Ignore event 
Transitions to Run 

Established 


Connection Not Applicable Ignore event Transition to | Ignore event | Ignore event 
Transitions to Recoverable 
Timed Out state Fault 


Fault Cleared Not Applicable | Not Applicable | Not Applicable Ignore event 
Run 
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Event State 


Non-Existent Available Recoverable | Unrecoverable 
Fault Fault 
Get_Attribute Return Error Return value Return value | Return value | Ignore event 
(Object Does 
Not Exist) 
Set_Attribute Return Error Accept value Accept value | Accept value | Ignore event 
(Object Does 
Not Exist) 
Off 


I/O Status LED Off Solid Green Flash Red Solid Red 


Attribute Access Rules 


Except in the Non-Existent and Unrecoverable Fault states, all attributes are gettable or settable 
according to their access rules. 


Because the only required Instance attribute is Value, the only required behavior of a Discrete 
Input Point is that it indicates a boolean value of OFF or ON. The optional attributes either 
provide more information about the discrete input point or alter the behavior of the input point. 


point transitions 


to ON > 
value = value = 
OFF <¢—______ ON 


point transitions 


The optional Status Instance attribute is simply a logical OR of all possible failure or alarm 
conditions for the point. 


Status , 
Failures or Alarms 
for specific point 
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5-10. 


5-10.1. 


5-10.2. 


Release 1.0 


DISCRETE OUTPUT POINT OBJECT 
Class Code: 09hex 


A Discrete Output Point (DOP) models discrete outputs in a product. You can use this object 
in applications such as discrete I/O control modules, relays, switches, etc. Note that the term 
“output” is defined from the network’s point of view. An output will consume data from the 

network. 


The Discrete Output Point interface is to real output points such as a relay or LED. The output 
is read from this object’s VALUE attribute and applied to the output terminal (e.g. screw 
terminal). 


Class Attributes 
Attribute Need in Access Name Data Description of | Semantics of Values 
ID Implementation Rule Type Attribute 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Instance Attributes 


Attribute Need in Access Name Data Description of | Semantics of Values 
ID Implementation Rule Attribute 
1 Optional Get Number of Number of 
Attributes attributes 
supported in this 
product 
2 Optional Get Attribute List List of attributes 
supported in this 
product 


Value BOOL Output point value | 0=off,; 
1=on 

Status BOOL Output point status |0=OK; 1=failure or 
alarm 


7 
Fault Value BOOL 


iL Optional Set Idle Action BOOL 


3 Required 


4 Optional 


Set 
Get 
Set Action taken on 0=Fault Value 
output’s value in | attribute; 


Recoverable Fault | 1=hold last state 
state 

User-defined value | 0=off; 

for use with Fault | 1=on 

State attribute 

Action taken on 0=Idle Value 
output’s value in attribute; 1=hold last 
Recoverable Fault | state 

state 


Optional 


6 Optional 


n 
fo) 
o 


Nn 


8 Optional Set Idle Value BOOL User-defined value | 0=off; 
for use with Idle 1=on 
State attribute 
9 Optional Set Run_Idle_ BOOL Generates the 0=Receive_Idle 
Command Receive_Idle or 1=Receive_Ready_to 
Receive_ _ Run 
Ready_to_ Run 
event 
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Attribute Need in Access Name Data Description of | Semantics of Values 
ID Implementation Rule Type Attribute 


10 Optional Set Flash Flash output at 0=no flash; 
periodic rate if 1=flash 
point is ON 

11 Optional Set Flash Rate Flash Rate for unsigned positive 
Flash attribute integer indicating 

frequency in Hz, e.g. 
= 1Hz 
Ge 


12 Optional t Object State | USINT State of the object | 1 = Non-Existent 
2 = Available 
3 = Idle 
4 = Ready 
5= Run 
6 = Recoverable 
Fault 
7 = Unrecoverable 
Fault 
255 = Reserved 


Important: Optional attributes either provide more information about the discrete output point 
or alter the behavior of the output point. If the following optional instance attributes are not 
supported, the default attribute values below indicate the required behavior for instances of 
this object class: 


Attribute Name Default 
ID Value 


5 _|FaultAcion | 0 
6 |FautVatie [0 
Tle Action [0 
¢ fale Vatue [0 

0 


10 Flash 


5-10.2.1 Value 


The only required Instance attribute is Value. The required behavior of a Discrete Output 
Point’s value is that it outputs a boolean value of OFF or ON. 


point transitions 
to ON 


value = value = 
OFF " ON 


point transitions 
to OFF 


5-10.2.2 Status 


The Status attribute is simply a logical OR of all possible failure or alarm conditions for the 


point. 
Status 
——_ Failures or Alarms 
for specific point 
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5-10.2.3 


Release 1.0 


Fault and Idle Attributes 


These optional attributes define a safe state for the DOP when in the Idle or Recoverable Fault 
States: 


e Fault Action 
e Fault Value 
e Idle Action 
e Idle Value 


This attribute pair Defines 


the value of the DOP in the Fault state. 
the value of the DOP in the Idle state. 


Fault Action and Fault Value 
Idle Action and Idle Value 


The following dependencies exist among these attributes: 


If this attribute is supported Then this attribute must also be 
supported by definition 


Fault Action Fault Value (although this attribute could 


be defined to always be OFF). 


Idle Action Idle Value (although this attribute could 
be defined to always be OFF). 


The “Action” attributes dictate what the DOP will do upon entering that state. The DOP will 
either hold its value in the last state or update it to the value stored in the corresponding Fault 
or Idle Value attribute. 


Upon entering the Recoverable_ Fault state the DOP will behave according to the following 
table. 


Fault_State = 0 Fault_State = 1 
Fault_Value = 0 DOP uses the value in the DOP leaves Value in last 
Fault_Value attribute (0) to state. Fault_Value attribute 
update its value. has no affect. 
Fault_Value = 1 DOP uses the value in the DOP leaves Value in last 
Fault_Value attribute (1) to state. Fault_Value attribute 
update its value. has no affect. 


The Idle attributes follow similar behavior. 


Important: There is one deviation from the behavior specified in the table above. If the DOP 
enters the Recoverable_Fault state from the Idle state in response to the I/O connection 
transitioning to Timed Out, the DOP’s value should go unchanged. This is shown in the 
DOP’s State Transition Diagram. 
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5-10.2.4 


5-10.2.5 


5-10.2.6 


5-10.3. 


5-10.3.1. 
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Run_Idle Command 


The Run Idle Command attribute causes the Receive Ready to Run or Receive Idle event to 
be sent to the DOP. Refer to the DOP’s State Transition Diagram to see the resulting 
transitions. This attribute only has effect when the Discrete Output object is in the Idle, Ready, 
or Run states. While in the Available or Recoverable Fault state, an attempt to set this attribute 
will result in an Object_State_Conflict error. A read (Get_Attribute_Single) of this attribute 
will result in a zero being returned always. 


Flash 
The Flash attribute modifies the behavior of the DOP such that when the DOP is in the ON 
state, the output flashes OFF and ON at a periodic rate. 


Flash Rate 


The Flash Rate attribute modifies the behavior of the DOP in that when the DOP is in the ON 
state and the Flash attribute is ON, it sets the periodic flash rate by an unsigned positive 
integer. 


Common Services 


The Discrete Output Object provides the following Common Services: 


Need in 
Implementation 


Condition | Required | Get_Attribute_Single 
al* 
Set_Attribute_ Single 


Get_Attributes_All 


Set_Attributes_All 


*The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 


Service Service Name 


Code 


Description of Service 


Returns the contents of the 
specified attribute. 


Modifies an attribute value. 


Returns a predefined listing of 
this objects attributes (See the 
Get_Attributes_All Response 
definition below) 


Modifies the contents of the 
attributes of the class or object. 


See the Appendix A for definitions of these common services. 


Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply data” 
portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 


0 Revision (low byte) Default = 1 
1 Revision (high byte) Default = 0 
2 Max Instance (low byte) Default = 0 
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Max Instance (high byte) Default = 0 
Max ID Number of Class Attributes (low byte) Default = 0 
Max ID Number of Class Attributes (high byte) Default = 0 
Max ID Number of Instance Attributes (low byte) Default = 3 
Max ID Number of Instance Attributes (high byte) Default = 0 


Important: Insert default values for all unsupported attributes. 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes All response is as follows: 


Bit 0 


Value 
Status 
Default = 0 
Fault State 
Default = 0 
Fault Value 
Default = 0 
Idle State 
Default = 0 
Idle Value 
Default = 0 


Flash 
Default = 0 


Flash Rate Default = 0 
Object State Default = 255 


Important: If the instance attribute Number of Attributes” is not supported, the default value 
of zero is to be inserted in its place and no members of the ”Attribute List” attribute will 
follow. 


Important: Insert default values for all unsupported attributes. 


5-10.3.2. Set_Attributes_All Request 


No settable attributes currently exist at the Class level for the Discrete Output Point object. 


At the Instance level, the order of attributes passed in the Set_Attributes All request is as 


follows: 

Byte Bit 0 
0 Value 
1 Fault Action 
2 Fault Value 
3 Idle State 
4 Idle Value 
5 0 0 0 0 (0) 0 (0) Flash 
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5-10.4. 


5-10.5. 


5-44 


6 Flash Rate 


Important: The Set_Attributes_All service is to be supported only if all settable attributes 
shown above are implemented as settable. 


Object—specific Services 


The Discrete Output Point Object provides no Object—specific services. 


Behavior 


The State Transition Diagram in Figure 5-10.1. provides a graphical description of the events 
and corresponding state transitions. A subset of the states and events may be supported in an 
application, but the behavior must be consistent. 


The State Event Matrix in this section lists all pertinent events and the corresponding action to 
be taken while in each state. 


Important: Events can occur simultaneously, but the Fault events have priority if they occur 


simultaneously with other events. In addition, if the Receive Data event occurs simultaneously 
with any other event, the other event takes precedence. 
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Figure 5-10.1. State Transition Diagram for Discrete Output Point Object 
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Receive_Ready_to_Run ecoverable 
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Fault_Cleared* -or- Connection 
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Note: LED = 1/0 Object Status LED 


Release 1.0 Open DeviceNet Vendor Assoc. & ControlNet International 5-45 


Chapter 5: Object Library Volume 1: CIP Common Specification 


The SEM contains the following states: 


e Non-Existent: module without power. 

e Available: DOP defaults configured, waiting for connection. 
e Idle: DOP in Idle mode and does not apply received data. 

e Ready: waiting for valid data to apply. 

e Run: DOP applying received data to its output. 

e Recoverable Fault: a recoverable fault has occurred. 

e Unrecoverable Fault: an unrecoverable fault has occurred. 


The SEM also contains these events: 


This event Is 


Receive_Data an event that signals the reception of I/O data and causes 
the object to transition to the Run state. 


Receive_Fault an event that is internally generated and product-specific. 
The network does not know if a Fault has occurred. 


Receive_Idle the setting of the Run_Idle Command attribute to the 
value 0 -or- the IO connection object receives an I/O 
message containing no application data 


Receive Run the setting of the Run_Idle Command attribute to the 
value 1. 
Apply_Attributes the Apply service of the I/O connection object the 


Discrete Output Point object is connected to. Note: the 
application is responsible for validating the connection 
object’s attributes. 


Connection Deleted I/O connection deleted. 
Connection Transitions to I/O connection transitions to Established. 
Established 


Connection transitions to the Timed | the expiration of the connection timer. 
Out state 
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Table 5-10.2 State Event Matrix for the Analog Input Point Object 
Event State 
Non - Available Ready Recoverable | Unrecoverable 
Existent Fault Fault 


Receive_Data Not If data length is} LED Solid | If data length Ignore event | Ignore event 
ee applicable non-zero Green, Accept is zero * 
transition to Data, Transition to 
Run Transition to Idle 


Verify and Run Otherwise 


Accept Data Verify and 


Transition to Accept Data 
RunlIgnore 


event 
Receive_Fault Not Transition to | Transitionto | Transition to | Ignore event | Ignore event 


applicable Recoverable | Recoverable | Recoverable 
Fault | Fault | Fault | 


Receive_Idle Return Error} Ignore event | Transition to | Transition to | Return Error 
(object state 


Ignore event 
Idle ” z (object state 


conflict) conflict) 
Receive_Ready_ Return Error} Transition to | Ignore event | Ignore event | Return Error| Ignore event 
to_Run i (object state Ready (object state 
conflict) conflict) 
Validate_Connection Verify Return Error | Return Error | Return Error | Return Error | Ignore event 
_ Attributes attributes, (object state (object state | (object state | (object state 
return results conflict) conflict) conflict) conflict) 

Connection Deleted Ignore event | Transition to | Transitionto | Transition to | Transitionto | Ignore event 

sieanik Available Available Available Available 
Connection Transition to | Return Error | Return Error | Return Error Transition to | Ignore event 
Transition to i Ready (object state (object state | (object state Ready ° 
Established conflict) conflict) conflict) 
Connection Not Not Transition to | Transitionto | Transition to | Ignore event | Ignore event 
transitions to applicable | applicable Recoverable | Recoverable | Recoverable 
Timed Out state Fault Fault Fault ' 
Get_Attribute Return Return value | Return value | Return value | Return value | Return value | Ignore event 

Error 
(Object 
Does 
Not Exist) 


Set_Attribute Return Verify, and Verify, and 
Error Accept, and Accept, and 


Verify, and | Verify, and 
Accept, and | Accept, and 
Apply value | Apply value 


Verify, and Ignore event 
Accept, and 


(Object | Apply value | Apply value 
Does 
Not Exist) 


Fault_Cleared Ignore Ignore event | Ignore event | Ignore event | Ignore event | Transition to | Ignore event 
event Ready ° 


1 - Fault: Hold Last State OR use Fault Value.- 
2 - Idle: Hold Last State OR use Idle Value. 
3 - If no other faults exist (Note, a Connection time out is considered a fault) 


Apply value 


Attribute Access 


Except in the Non-Existent and Unrecoverable Fault states, all attributes are gettable or settable 
according to their access rules. 
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5-11. ANALOG INPUT POINT OBJECT 
Class Code: 0Ahex 


The Analog Input Point (AIP) Object models analog inputs in a product. It can be used in 
applications as simple as a single analog point and as complex as an analog I/O control module. 
Note that the term ”input” is defined from the network’s point of view. An input will produce 
data on the network. 


The Analog Input Point interface is to real input points such as a thermocouple or pressure 
transducer. The input is sampled and the data is stored in this object’s VALUE attribute. A 
sample of the analog input value is triggered via an external command (input change-of-state, 
cyclic data trigger, etc.) 


5-11.1. Revision History 


Since the initial release of this object class definition changes have been made that require a 
revision update of this object class. The table below represents the revision history: 


Revision Reason for object definition update 
01 Initial Definition at First Release of Specification 
02 IDLE state removed from this object’s behavior 


5-11.2. Class Attributes 


Attr ID Need in Access Name Data Description of Semantics of Values 
Implementation | Rule Type Attribute 
1 Required Get Revision UINT Revision of this | The current value assigned 
object to this attribute is two (02). 


2 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


5-11.3. Instance Attributes 


Attr ID Need in Semantics of Values 
Implementation | Rule Type Attribute 
1 Optional Get Number of | USINT Number of 
Attributes attributes 
supported 
List USINT supported by the 
point 


3 Required Get Value INT or Analog input 
based on | value. The data 
attribute 8 | type defaults to 
INT but may be 
changed based on 
attribute 8. 
4 Optional Get Status BOOL Indicates if a fault | O= operating without 
or alarm has alarms or faults. 
occurred. 1=alarm or fault condition 
exists, the Value attribute 
may not represent the actual 
field value. 
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Name Data Semantics of Values 
Implementation | Rule Type Attribute 
Optional Get Owner UINT Vendor ID of 
Vendor ID channel’s owner 
Optional Get Owner Serial | UDINT 32-bit serial 
number of 
channel’s owner 


Set Input Range | USINT Input range the 0 =-10V to 10V 
point is operating | 1 =0V to5V 
in 2 =0V to 10V 
3 =4mA to 20mA 
4=-15mV to 75mV 
5 =-15mV to 30mV 
6 =-5V to 5V 
7=1Vto5V 
8 = 0mA to 20mA 
9 =0mA to 50mA 
10 — 99 = Reserved 
100-13 1=Vendor Specific 
132-154 =Reserved 
255 = Only return with 
Get_Attributes_All if 
attribute not supported 
Optional Value Data | USINT Determines the 0=INT 
data type of 1 =REAL 
Value 2 = USINT 
3 = SINT 
4=DINT 
5 =LINT 
6 = UINT 
7 = UDINT 
8 = ULINT 
9 = LREAL 
100 = vendor specific 


5-11.4. Common Services 


The Analog Input Object provides the following Common Services: 


Service Service Name Description of Service 
Code 


OEhex |Required | Required Get_Attribute Single | Returms the contents of the 
specified attribute. 
10hex Conditional! |Set_Attribute_Single | Modifies an attribute value. 


Olnex | Optional Optional Get_Attributes_All Returns a predefined listing of this 
objects attributes (See the 
Get_Attributes_All Response 
definition below) 


O2hex | n/a Optional Set_Attributes_All Modifies the contents of the 
attributes of the class or object. 


'The Set_Attribute_Single service is required only if Instance Attributes 7 and/or 8 are implemented. 
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5-11.4.1.  Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply data” 
portion of the Get_Attributes_All response is as follows: 


0 Revision (low byte) Default = 2 
Revision (high byte) Default = 0 
Max Instance (low byte) Default = 0 
Max Instance (high byte) Default = 0 
Max ID Number of Class Attributes (low byte) Default = 0 
Max ID Number of Class Attributes (high byte) Default = 0 
Max ID Number of Instance Attributes (low byte) Default = 3 
Max ID Number of Instance Attributes (high byte) Default = 0 


NALA] ALR lwlNMp]re 


Important: Insert default values for all unsupported attributes. 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 


Number of Attributes Default = 0 


Attribute List (attribute #1) 


Attribute List (attribute #m) 


Value Data Type Default = 0 


Value (low byte) 


Value (high byte) 


Status 
ab = 


Owner Vendor ID (low byte) Default = 
Owner Vendor ID (high byte) Default = 0 
Owner Serial Number (low byte) Default = 0 
Owner Serial Number Default = 0 
Owner Serial Number Default = 0 
Owner Serial Number (high byte) Default = 0 


Input Range Default = 255 * 


The default value of 255 must be returned for the Input Range attribute ONLY if it is not 
supported by the device. 


5-50 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 5: Object Library 


Important: Insert default values for all unsupported attributes. 


Important: If the instance attribute Number of Attributes” is not supported, the default value 
of zero is to be inserted in its place and no members of the ”Attribute List” attribute will 
follow. 


5-11.4.2. Set_Attributes_All Request 
No settable attributes currently exist at the Class level for the Analog Input Point object. 


At the Instance level, the order of attributes passed in the Set_Attributes All request is as 
follows: 


Input Range 


Value Data Type 


Important: The Set_Attributes_All service is to be supported only if all settable attributes 
shown above are implemented as settable. 


5-11.5. Object—specific Services 
The Analog Input Object provides no Object—-specific services: 


5-11.6. Behavior 


The State Transition Diagram in Figure 5-11.1. provides a graphical description of the events 
and corresponding state transitions. A subset of the states and events may be supported in an 
application, but the behavior must be consistent. 


The State Event Matrix in this section lists all pertinent events and the corresponding action to 
be taken while in each state. A subset of the states and events may be supported in an 


application, but the behavior must still be consistent. 


Figure 5-11.1. State Transition Diagram for Analog Input Point Object 
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Important: Events can occur simultaneously, but the Fault events have priority if they occur 
simultaneously with other events. 


The SEM contains the following states: 
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Non-Existent: module with no power. 

Available: waiting for a connection, power-up analog input point defaults are set. 
Run: AIP sensing data from its input and transmitting the data. 

Recoverable Fault: a recoverable fault has occurred. 

Unrecoverable Fault: an unrecoverable fault has occurred. 
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The SEM also contains these events: 


This event Is 
Sample Trigger a change of state; cyclic timer trigger; non—zero length Bit Strobe or Poll 
Command. 
Connection Deleted I/O connection deleted. 
Apply_Attributes the Apply service of the I/O connection object the Analog Input Point object is 


connected to. Note: the application is responsible for validating the connection 
object’s attributes. 


Fault Cleared the application clearing a detected fault 


Connection Transitions | I/O connection transitions to Established. 
to Established 


Connection Transitions | I/O connection transitions to Timed-Out 
to Timed Out state 


The figure below is a conceptual illustration of the state machine for a typical input object 


(producing application). The events listed above are represented by the dotted line labeled 
“state change.” 
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Table 5-11.2. State Event Matrix for the Analog Input Point Object 


Event State 


Fault Fault 
Sample Trigger Ignore event Ignore event 
Send data 


Apply Attributes Not Applicable | Verify attributes, | Return error Return error Ignore event 
return result (Object State (Object State 
Conflict) Conflict) 


Connection Deleted Transition to Ignore event 
Available Available 

Connection Transitions Ignore event 

to Established Run 


Connection Transitions | Not Applicable Ignore event Transition to Ignore event Ignore event 
to Timed Out state Recoverable 
Fault 
Run 


Get_Attribute Return Error Return value Return value Ignore event 
(Object Does 
Not Exist) 
Set_Attribute Return Error Accept value | Accept value Ignore event 
(Object Does 
Not Exist) 


I/O Status LED Flash Green Solid Green Flash Red Solid Red 


Attribute Access Rules 


Except in the Non-Existent and Unrecoverable Fault states, all attributes are gettable or settable 
according to their access rules. 


Because the only required Instance attribute is Value, the only required behavior of an AIP is 
that it indicates an analog value. 


Optional attributes either provide more information about the AIP or alter the behavior of the 
input point. 


The optional Status attribute is simply a logical OR of all possible failure or alarm conditions 
for the point. 


Status 


Failures or Alarms 
for specific point 


The Owner Vendor ID and Owner Serial Number are included in the object definition but their 
use is TBD. 


The Input Range attribute determines the set of analog values within which the inputs may 


operate. The value of the Input Range affects the default and legal values that other attributes 
may have. 
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Input Range is necessary only if the point may be switched to operate within different ranges, 
which changes the behavior of the point. For example, if the point is configured to operate from 
OV to 5V or from 4mA to 20mA, the variability of ranges will likely change the expected 
behavior of the Value attribute and perhaps change vendor specific attributes. 


The Value Data Type attribute determines the data type to be used by the attribute Value (and 
perhaps other attributes as well). If Value Data Type is not used, then Value defaults to INT. 
Value (and other attributes) may behave as REAL, USINT, or any other data type based upon 
the definition of Value Data Type, which ultimately provides the ability for the analog point to 
be defined in any length necessary 
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5-12.1. 


5-12.2. 
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ANALOG OUTPUT POINT OBJECT 
Class Code: OBhex 


The Analog Output Point (AOP) models the point level attributes and services of the analog 
outputs in a product. It can be used to model voltage output or parts of an analog I/O control 
module. Note that the term ’output” is defined from the network’s point of view. An output 
will consume data from the network. 


The Analog Output Point interface is to real output points such as a Motor Operated Valve 


(MOV) or Linear Positioner. The output is read from this object’s VALUE attribute and 
applied to the output terminal (e.g. screw terminal). 


Class Attributes 


Need in Access Name Data Type | Description of 
Implementation | Rule Attribute 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Semantics of Values 


Instance Attributes 


Implementation | Rule Attribute 
1 Optional Get Number of | USINT Number of 0-255 
Attributes attributes 
supported 
List USINT supported by the 
point 


3 Required Set Value INT or based | Analog output 
on attribute | value. The data 
8 type defaults to 
INT but may be 
changed based on 
attribute 8. 
4 Optional Status BOOL Indicates if a fault | O= operating without 
or alarm has alarms or faults. 
occurred. 1=alarm or fault condition 
exists, the Value attribute 
may not represent the 
actual field value. 


Vendor ID channel’s owner 
6 —— Owner - UDINT 32-bit serial 

Serial number of 

Number channel’s owner 
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Attr ID Need in 


7 Optional Output USINT Specifies the 
Range output range the 
output channel is 
to use 
8 Optional Value Data | USINT Determines the 
data type of 
Value 


9 Optional Set Fault State | USINT Output value to 
go to on failure or 
fault 


10 Optional Idle State USINT Output value to 
go to on idle 
mode 

11 Optional Fault Value | INT or based | User defined 

on attribute | value outputs go 

8 to in fault mode 
if Fault State = 3, 
user specified 
value 

12 Optional Idle Value INT or based | User defined 

on attribute | value outputs go 

8 to in idle mode if 
Idle State = 3, 
user specified 
value 


Changes state of 
AOP to Idle 
Mode or Run 
Mode 
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Access Name Data Type | Des6cription of Semantics of Values 
Implementation | Rule Attribute 


0 =4mA to 20mA 

1=0V to 10V 

2=0mA to 20mA 
=-10V to 10V 

4=0V to 5V 

5=-5V to5V 

6=1Vto5V 

7 - 8 = Reserved 

9 =0mA to 50mA 

10 — 99 = Reserved 

100-131=Vendor Specific 

132 — 254 = Reserved 

255 = Only return with 

Get_Attributes_All if 

attribute not supported 

0=INT 

1 =REAL 

2 = USINT 

3 = SINT 

4 = DINT 

5 = LINT 

6 = UINT 

7 = UDINT 

8 = ULINT 

9 =LREAL 

100 = vendor specific 

0 = hold last state 

1 = low limit 

2 = high limit 

3 = user specified value 

0 = hold last state 

1 = low limit 

2 = high limit 

3 = user specified value 


0 = idle 
1=run 
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Attr ID Need in Access Name Data Type | Des6cription of Semantics of Values 
Implementation | Rule Attribute 


14 Optional Get Object State | USINT State of the object | 1 = Non-Existent 
2 = Available 
3 =Idle 
4 = Ready 
5= Run 
6 = Recoverable Fault 
7 = Unrecoverable Fault 
255 = Reserved 


Important: If the following optional instance attributes are not supported, the default attribute 
values below indicate the required behavior for instances of this object class: 


Attribute Default Value 
ID 


p 0 
8 Value Data 0 
9 0 
10 0 


11 Fault Value minimum value of range 
(attribute 7) 


12 Idle Value 0 


5-12.3. Common Services 
The Analog Output Object provides the following Common Services: 


Service Need in Service Name Description of Service 
Code Implementation 


OEhex | Conditional* | Required | Get_Attributes_Single | Returns the contents of the specified 
attribute. 
10hex Set_Attributes Single | Modifies an attribute value. 


Olhex | Optional Optional | Get_Attributes_All Returns a predefined listing of this 
objects attributes (See the 
Get_Attributes_All Response 
definition below) 


O2hex | n/a Optional | Set_Attributes_All Modifies the contents of the 
attributes of the class or object. 


*The Get_Attribute_Single service is REQUIRED if any class attributes are implemented. 


See the Appendix A for definitions of these common services. 


5-12.3.1. Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply data 
portion of the Get_Attributes_All response is as follows: 


” 


Revision (low byte) Default = 1 
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1 Revision (high byte) Default = 0 
Max Instance (low byte) Default = 0 
Max Instance (high byte) Default = 0 
Max ID Number of Class Attributes (low byte) Default = 0 
Max ID Number of Class Attributes (high byte) Default = 0 
Max ID Number of Instance Attributes (low byte) Default = 3 
Max ID Number of Instance Attributes (high byte) Default = 0 


SLA] nA], R][ Ww] hd 


Important: Insert default values for all unsupported attributes. 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 


Value (low byte) 


Value (high byte) 
Number of Attributes Default = 0 


Attribute List (attribute #1) 


Attribute List (attribute #m) 


Status 
Default = 0 


Owner Vendor ID (low byte) Default = 
Owner Vendor ID (high byte) Default = 0 
Owner Serial Number (low byte) Default = 0 
Owner Serial Number Default = 0 
Owner Serial Number Default = 0 
Owner Serial Number (high byte) Default = 0 
Output Range Default = 255 
Value Data Type Default = 0 
Fault State Default = 0 
Idle State Default = 0 
Fault Value (low byte) 

Fault Value (high byte) 
Idle Value (low byte) 
Idle Value (high byte) 


Command 
Default = 0 


Object State Default = 255 


Important: Insert default values for all unsupported attributes. 
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The default value of 255 must be returned for the Output Range attribute ONLY if it is not 
supported by the device. 


Important: If the instance attribute Number of Attributes” is not supported, the default value 
of zero is to be inserted in its place and no members of the ’Attribute List” attribute will 
follow. 


5-12.3.2.  Set_Attributes_All Request 
No settable attributes currently exist at the Class level for the Analog Output Point object. 


At the Instance level, the order of attributes passed in the Set_Attributes All request is as 
follows: 


Value (low byte) 


n Value (high byte) 
N+1 Output Range 
Value Data Type 
Fault State 
Idle State 
Fault Value (low byte) 
Fault Value (high byte) 
Idle Value (low byte) 


Idle Value (high byte) 


Important: The Set_Attributes_All service is to be supported only if all settable attributes 
shown above are implemented as settable. 
5-12.4. Object—specific Services 


The Analog Output Point Object provides no Object-specific services. 


5-12.5. Behavior 


The State Transition Diagram in Figure 5-12.1. provides a graphical description of the events 
and corresponding state transitions. A subset of the states and events may be supported in an 
application, but the behavior must be consistent. 


The State Event Matrix in Table 5-12.2 lists all pertinent events and the corresponding action to 


be taken while in each state. A subset of the states and events may be supported in an 
application, but the behavior must still be consistent. 
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Release 1.0 


Important: Events can occur simultaneously, but the Fault events have priority if they occur 
simultaneously with other events. In addition, if the Receive_Data event occurs simultaneously 
with any other event, the other event takes precedence. 


Figure 5-12.1. State Transition Diagram for Analog Output Point Object 
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The following SEM contains these states: 


e Non-Existent: module without power. 

e Available: AOP defaults configured, waiting for connection. 
e Idle: AOP in standby mode and does not apply received data. 
e Ready (to run): waiting for valid data to apply. 

e Run: AOP applying received data to its output. 

e Recoverable Fault: a recoverable fault has occurred. 

e Unrecoverable Fault: an unrecoverable fault has occurred. 


The SEM also contains these events: 


This event Is 


Receive_Data an event that signals the reception of I/O data and causes the object to 
transition to the Run state. 


Receive_Fault an event that is internally generated and product-specific. The network 
does not know if a Fault has occurred. 


Receive_Idle the setting of the COMMAND attribute to the value 0 -or- within the 
Master/Slave paradigm the event signaled when the I/O connection object 
receives a Bit-Strobe or Poll Command message containing no 
application data 


Receive_Run the setting of the COMMAND attribute to the value 1 -or- within the 
Master/Slave paradigm the event signaled when the I/O connection object 
receives a Bit-Strobe or Poll Command message containing application 
data 


Apply_Attributes the Apply service of the I/O connection object the Analog Output Point 
object is connected to. Note: the application is responsible for validating 
the connection object’s attributes. 


Connection Deleted I/O connection deleted. 
Connection Transitions to I/O connection transitions to Established. 
Established 


Connection transitions to the Timed _| the expiration of the connection timer. 
Out state 


The figure below is a conceptual illustration of the state machine for a typical output object 


(consuming application). The events listed above are represented by the dotted line labeled 
“state change.” 
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Table 5-12.2. State Event Matrix for the Analog Output Point Object 


Event State 


Non-Existent Available Ready Recoverable | Unrecoverable 
Fault Fault 


Receive_Data Not applicable | Not applicable | Ignore event | LED Solid | Accept Data | Ignore event | Ignore event 
Green, Accept 
Data, 
Transition to 
Run 


Transition to | Transition to | Ignore event | Ignore event 
Recoverable | Recoverable | Recoverable 
Fault | Fault | 


Receive_Idle Not applicable | Not applicable | Ignore event | Transition to | Transition to | Transition to | Ignore event 
Idle * Idle * Idle * 
Receive_Run Not applicable | Not applicable | Transition to | Ignore event | Ignore event | Transition Ignore event 
Ready to 
Ready 


Transition to 


Receive_Fault Not applicable | Not applicable 


Apply_Attributes | Not applicable Verify Return Error | Return Error | Return Error | Return Error | Ignore event 
attributes, (object state | (object state | (object state | (object state 
return results conflict) conflict) conflict) conflict) 
Connection Not applicable | Ignore event | Transition to | Transition to | Transition to | Transition to | Ignore event 
Deleted Available Available Available Available 
Connection Not applicable | Transition to | Return Error | Return Error | Return Error | Transition Ignore event 
Transition to Ready (object state | (object state | (object state to 


Established conflict) conflict) conflict) Ready 


Connection Not applicable | Not applicable | Transition to | Transition to | Transition to | Ignore event | Ignore event 


transitions to Recoverable | Recoverable | Recoverable 
Timed Out state Fault Fault 


Get_Attribute Return Error | Return value | Return value | Return value | Return value | Return value | Ignore event 
(Object Does 
Not Exist) 
Set_Attribute Return Error | Accept value | Accept value | Accept value | Accept value | Accept value | Ignore event 
(Object Does 
Not Exist) 


1 - Fault: Hold Last State OR use Fault Value. 
2 - Idle: Hold Last State OR use Idle Value. 


Attribute Access Rules 


Except in the Non-Existent and Unrecoverable Fault states, all attributes are gettable or settable 
according to their access rules. 


Because the only required Instance attribute is Value, the only required behavior of a Analog 


Output Point is that it outputs an analog value within the defined range for value (see Instance 
Attribute 8). 
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Optional attributes either provide more information about the AOP or alter the behavior of the 
output point. 


The optional Status attribute is simply a logical OR of all possible failure or alarm conditions 
for the point. 


Status 


Failures or Alarms 
for specific point 


The Command attribute explicitly controls whether the AOP is in the Run or Idle state. It has 
effect only when the Discrete Output object is in the Idle, Ready, Recoverable Fault or Run 
states. While in the Available state, an attempt to set this attribute will result in an 
Object_State Conflict error. A read (Get_Attribute_Single) of this attribute will result in a zero 
being returned always. 


These optional attributes define a “safe state” for the analog output point when in the Idle or 
Fault states: 


e Output Fault State 
e Output Fault Value 
e Output Idle State 

e Output Idle Value 


This attribute pair Defines 
Output Fault State and the value of the AOP in the Recoverable Fault state 
Output Fault Value 
Output Idle State and the value of the AOP point when in the Idle state 
Output Idle Value 


The following dependencies exist among these attributes: 


If this attribute is 
supported 
Output Fault State 
Output Idle State 


Then this attribute must also be supported by definition 


Fault Value (although this attribute could be defined to always be LOW). 
Idle Value 
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The Owner Vendor ID and Owner Serial Number are included in the object definition but their 
use is TBD. 


The Output Range attribute determines the set of analog values within which the outputs may 
operate. The value of the Output Range affects the default and legal values that other attributes 
may have. 


Output Range is necessary only if the point may be switched to operate within different ranges, 
which changes the behavior of the point. For example, if the point is configured to operate from 
-10V to 10V or from OV to 10V, the variability of ranges will likely affect the low value that 
outputs go to in safety state (you can use -10 V or 0 V, Output Range). 


The Value Data Type attribute determines the data type to be used by the attribute Value (and 
perhaps other attributes as well). If Value Data Type is not used, then Value defaults to INT. 
Value (and other attributes) may behave as REAL, USINT, or any other data type based upon 
the definition of Value Data Type, which ultimately provides the ability for the analog point to 
be defined in any length necessary. 
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PRESENCE SENSING OBJECT 
Class Code: OEhex 


This object senses the presence or absence of a real world target. 


Class Attributes 


Attribute Need in Access Name Data Type | Description of Semantics of 
ID Implementation | Rule Attribute Values 


1 thru7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Instance Attributes 
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Attr Need in Access Name Data Type Description of Attribute Semantics of 
ID | Implementation] Rule Values 
1 Required Get Output BOOL 0 = switching element open | See Semantics” 
= switching element closed | section 


2 Optional Get Number of USINT Number of attributes 
Attributes supported 
3 Optional Get Attribute Array of List of attributes supported 
List USINT 
4 Optional Diagnostic 0=good 
aa Ce =fault 
7 One Shot Delay_| UINT 0 — 65,535 ms 
8 Optional Set Operate Mode |BOOL 0 = output attribute as See Semantics” 
specified section 
1 = inversion of output 
attribute 
9 


Optional Set Sensitivity USINT 0-255 See Semantics” 
section 


10 ‘| Optional Get Target Margin | USINT 1-255 See Semantics” 
section 

11 ‘| Optional Get Background USINT 0-100 See Semantics” 
Margin section 


12 | Optional Set Min Detect UINT 0-— 65,535 mm See Semantics” 
Distance section 

13 | Optional Set Max Detect UINT 0 — 65,535 mm * See Semantics” 
Distance section 


* The Max Detect Distance must be greater than or equal to the Min Detect 
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Distance 

Semantics: 

Output 

The Output value is determined by the switching element in the device. The state of this value 


is controlled by the: 


e operation mode: Light Operate (LO)/Dark Operate (DO) 
Normally Closed (NC)/Normally Open (NO) 

e detection of an object (absence or presence) 

e timing 

e type of device (photoelectric, proximity) 


The following table indicates output values for common presence sensing devices. 


Presence Sensing Device Output Values 


Output = Off 
Diffuse Photoelectric, light detected (LO) no light detected (LO) 
Retroreflective Photoelectric no light detected (DO) light detected (DO) 
Through—Beam Photoelectric light beam detected (LO) light beam interrupted (LO) 
light beam interrupted (DO) light beam detected (DO) 


Inductive Proximity, Capacitive, | object present (NO) object absent (NO) 
Ultrasonic, Limit Switch object absent (NC) object present (NC) 


Operate Mode 


Use the Operate (Sensing) Mode to invert the level definition of the Output attribute. 


For use the Operate Mode to: 
set Light Operate (LO)/Dark Operate (DO) mode. 


set Normally Open (NO)/Normally Closed (NC) mode. 


photoelectric sensors, 


proximity sensors, 
Sensitivity 
Sensitivity is the amplification of the signal received by the detection device. Sensitivity is 
defined with either of two methods (i.e. low, medium, high or a numeric scale). This attribute 


accommodates both methods by converting the terms into a numeric scale 
(i.e. 0 = lowest, ... , n = highest). 


Target Margin 

Target Margin is the signal strength received by the device when the signal strength is above 
the device output switching threshold. The margin value is a scale of 1 to 255 with 1 
representing the device output switching threshold. 

Background Margin 

Background Margin is the signal strength received by the device when the signal strength is 


below the device output switching threshold. The margin value is a scale of 0 to 100 where the 
value 100 equals the device switching threshold and the value 0 represents no signal received. 
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Minimum and Maximum Detect Distances 


The Minimum and Maximum Detect Distances define the range in which an object can be 
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detected. If an object passes through the sensing device’s field of view outside this range, the 


sensing device does not change the output (attribute number 1) of the device to indicate 


detection of that object. 


Common Services 


The Presence Sensing Object provides the following Common Services: 


Service Need in Service Name Description of Service 
Code Implementation 


OEpex | Conditional* | Required |Get_Attributes_Single | Returns the contents of the 
specified attribute. 


10hex Set_Attributes Single | Modifies an attribute value. 


*The Get_Attribute_ Single service is REQUIRED if any attributes are implemented. 


See the Appendix A for definitions of these common services. 


Object-specific Services 


The Presence Sensing Object provides no Object—specific services. 


Behavior 


The behavior of the Presence Sensing Object is illustrated in the State Transition Diagram and 


State Event Matrix in this section. Table 5-13.1.indicates the accessibility of attributes. 


Non-Existent 


Connection 
Established 


Connection 
Deleted 


State 


Connection established Ignore event 
Connection deleted Transition to Non-Existent 
Get_Attribute_ Single Return value 
Set_Attribute_ Single Accept value 


Table 5-13.1. Presence Sensing Object Attribute Access 


Attribute State 
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Output 

Number of Attributes 
Attribute List 
Diagnostic 

On Delay 

Off Delay 

One Shot Delay 
Operate Mode 
Sensitivity 

Target Margin 
Background Margin 
Min Detect Distance 
Max Detect Distance 


Detect Distance 
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Non-Existent Running 


ot available Read Only 
ot available Read Only 
ot available Read Only 
ot available Read Only 
ot available Read/Write 
ot available Read/Write 
ot available Read/Write 
ot available Read/Write 
ot available Read/Write 
ot available Read Only 
ot available Read Only 
ot available Read/Write 
ot available Read/Write 


ot available Read Only 
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5-14 PARAMETER OBJECT 
Class Code: 0Fhex 


Use of the Parameter Object provides a known, public interface to a device’s configuration 
data. In addition, this object also provides all the information necessary to define and describe 
each of a device’s individual configuration parameters. 


This object allows a device to fully identify a configurable parameter by supplying a full 
description of the parameter, including minimum and maximum values and a human-readable 
text string describing the parameter. 


There must be one instance of this object class for each of the device’s configurable 
parameters. The instances must start at instance one and increment by one with no gaps in the 
instances. 


Each instance is linked to one of the configurable parameters, which is typically (but is not 
required to be) an attribute of one of the device’s other objects. Changing the Parameter Value 
attribute of a Parameter Object causes a corresponding change in the attribute value indicated 
by the Link Path attribute (the attribute value being pointed to by the Parameter Object). 


For example, Instance #1 of the Parameter Object below identifies the parameter represented by 
the Analog Input Point (AIP) Object, Instance #1, Attribute #7. 


Device 
AIP 
Instance #1 


Parameter 
Class 
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5-14.1. Class Attributes 
Attribute Need in Access Name Data Type 

ID Implementation] Rule 
| 7 


et 
2 Required Get Max UINT 
Instance 


3 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


8 Required WORD Bits that describe | See Table 6.J. 
parameters. 

| 

6=Portugese 


10 Optional Set 
7=Mandarin Chinese 


* Tf the value is 01, then this attribute is OPTIONAL in implementation. If the value is greater than 01, then this 
attribute is REQUIRED. 


Description of Semantics of Values 
Attribute 


Revision of this The current value 
object assigned to this attribute 
is one (01). 


Maximum The largest instance 
instance number | number of a created 
of an object object at this class 
currently created | hierarchy level. 

in this class level 

of the device. 


Parameter 
Class 
Descriptor 


UINT Instance number | This attribute should be 
of the set to zero ifa 
configuration configuration assembly is 


assembly. not supported. 


Configuration 
Assembly 
Instance 


USINT Language ID for | 0=English 
all character 1_French 


array accesses. 2=Spanish 
3=Italian 
4=German 


5=Japanese 


The Parameter Class Descriptor attribute contains bits to describe parameter characteristics. 
The following bits are supported: 


Table 5-14.1. Parameter Class Descriptor Bit Values 


Definition 
Supports Parameter Instances 
Supports Full Attributes 


Must do non-volatile storage save command 


Params are stored in Non-Volatile storage 


“Supports Parameter Instances” indicates that Parameter Instances are present for 
each parameter. Parameter Instances contain all attributes or just the stub attributes. 
Bit values are: 


Value Meaning 


Individual Parameter instances ARE supported. 
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5-14.2. 


Release 1.0 


0 NO Parameter Instances are supported. Only configuration assembly instance used. 


“Supports Full Attributes” indicates that each Parameter Instance contains all of the attributes 
and are not just stubs. Bit values are: 


Meaning 
All Full Parameter Attributes ARE supported. 


Only Parameter Instance stub attributes are supported. 


“Must Do NV Storage Save Command” indicates that parameters are not stored into NV 
storage until a Save service is performed on the Parameter Object. 


Meaning 
Must execute non—volatile storage save command. 


Do not have to execute non—volatile storage save command. 


“Params are stored in Non—Volatile Storage” indicates that parameters are stored in non— 
volatile storage. Bit values are: 


Meaning 
All Full parameters are stored in non—volatile storage. 


Parameters are not stored in non—volatile storage. 


A Parameter Object Stub is a shorthand version of a parameter object. The stub stores only the 
configuration data value, providing only a standard access point for the parameter. 


Instance Attributes 


ID_| Implementation | Rule | Full Values 

1 | Required Set Stub | Parameter | data type Actual value of parameter. 

Value specified in It can be read from or 
Descriptor, Data | written to. This attribute is 
Type and Data | read-only if bit 4 of 
Size. Attribute #4 is TRUE. 
2 | Required Set Stub |Link Path | USINT Size of link path. If this Number of 
Size attribute is 0, then no link | bytes. 
is specified. 

3 | Required Set Stub |Link Path | Packed EPATH | CIP path to the object The Link Path 
from where this is limited to 
parameter’s value is 255 bytes. See 
retrieved. Appendix C. 


Table 6.K. 
5 | Required Get Stub | Data Type | EPATH Data type code. See Volume C, 
Section C-6.1 
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Attr Need in Access | Stub/ Name Data Type Description of Attribute | Semantics of 
ID _| Implementation | Rule | Full Values 


6 | Required Stub | Data Size | USINT Number of bytes in 
Parameter Value 
7 | Optional Parameter | SHORT A human-readable string |The maximum 


Name STRING representing the parameter | number of 
String name. For example, characters is 16 
“Frequency #1” 


ae 

Full Units SHORT_ Engineering Unit String The maximum 

String STRING number of 
characters is 4 
Full Help SHORT_ Help String The maximum 

String STRING number of 
characters is 64 
10 | Optional Full Minimum | data type The minimum valid actual 
Value value to which the 
parameter can be set. 
11 | Optional Full Maximum | data type The maximum valid actual 
Value value to which the 
parameter can be set. 


12 | Optional 


Full Default data type The actual value the 
Value parameter should be set to 
when the user wants the 
default for the parameter. 
Full Scaling UINT Multiplier for Scaling See 
Multiplier Factor. Figure 6.7. 
Scaling UINT Divisor for Scaling See 
Divisor Formula. Figure 6.7. 
UINT 
INT 


13 | Optional 


Nn 
ie) 
as 
aa 
° 
5 
oF 


er 


Scaling Base for Scaling Formula. | See 
Base Figure 6.7. 


Offset for Scaling See 
Formula. Figure 6.7. 


Full Multiplier | UINT Parameter Instance of See Table 6.N. 
Link Multiplier source. 
Divisor UINT Parameter Instance of See Table 6.N. 
Link Divisor source. 
Base Link | UINT Parameter Instance of See Table 6.N. 
Base source. 
IN 


Ful 
Ful 
Full 


nN 
ie) 
as 
=e 
° 
5 
©. 


Scaling 
Offset 


(Can be 
negative) 


~ 
© 
as 
=e 
° 
5 
©. 


oo 
© 
as 
= 
° 
5 
©. 


Full 


\o 
© 
as 
=a 
° 
5 
2. 


Full 


N 
S 
o 

g 
a. 
° 
5 
2. 


& 
© 
as 
=o 
° 
5 
2. 


Link 


G Full Decimal | USINT Specifies number of 
Precision decimal places to use 

when displaying the 
scaled engineering value. 
Also used to determine 
actual increment value so 
that incrementing a value 
causes a change in scaled 
engineering value to this 
precision. 


The Descriptor Instance Attribute contains these bits, which describe the parameter: 


Offset Parameter Instance of See Table 6.N. 
Offset source. 


Get 
Get 
Get 
Get 
Get 
Get 
Get 
Get 
Get 
Get 
G 
Get 
Get 
Get 
Get 
et 


N 
= 
ie 
as 
a. 
° 
5 
2. 


Table 5-14.2. Semantics of Descriptor Instance Attribute 
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0 | Supports Settable Path Indicates that link path can be set. 


Supports Enumerated Strings | Indicates that enumerated strings are supported and can be read 
with the Get_Enum_String service. 


2 | Supports Scaling Indicates that the scaling factor should be implemented to 
present the value to the user in engineering units. 


3 | Supports Scaling Links Indicates that the values for the scaling factor may be retrieved 
from other parameters. 


4 |Read Only Parameter Indicates that the value attribute can only be read, and not set. 


5 |Monitor Parameter Indicates that the value attribute is updated in real time by the 
device. 


6 | Supports Extended Precision | Indicates that the extended precision scaling factor should be 
Scaling implemented to present the value to the user in engineering 
units. 


7 |Supports non-consecutive Indicates that non-consecutive enumerated strings are 
enumerated strings supported. 


8 | Allows both enumeration Both enumeration and individual values are supported. 
and individual values 


The Data Type Instance Attribute specifies the data type of the parameter. This value shall be 
specified according to the format shown in Volume I, Appendix J, Section J-6.1. The 
following data types are obsolete but may be encountered in older devices: 


Table 5-14.3. Obsolete Data Types Possible in the Parameter Object 


Attr Description 
Value 
; eae 
2 16-bit unsigned integer 
3 INT 16-bit signed integer 
4 Boolean 
5 Short Integer 
6 Double Integer 
7 Longdnteger 
8 Unsigned Short Integer 
9 Unsigned Double Integer 
0 Unsigned Long Integer 
1 Single floating point format (IEEE 754) 
2 Double floating point format (IEEE 754) 
3 Duration (short) 
4 Duration 
5 Duration (high resolution) 
6 Duration (long) 
| Date (See Appendix J Volume I) 
8 Time of day (See Appendix J Volume I) 
9 Date and Time (See Appendix J Volume I) 
20 8-bit per character string 
21 16-bit per character string 


Release 1.0 Open DeviceNet Vendor Assoc. & ControlNet International 5-75 


Chapter 5: Object Library Volume 1: CIP Common Specification 


Attr Definition Description 
Value 

22 STRINGN N-byte per character string 

23 SHORT STRING Short N-byte character string 


24 BYTE 8-bit string 
25 DWORD 32-bit string 


26 LWORD 64-bit string 
Obsolete data type codes shall not be valid in devices developed to this specification. 


The Scaling Factor represents actual UINT and INT parameter values in other formats. Use the 
following formula to determine the engineering value from the actual value: 


Figure 5-14.4. Determining Engineering Value from Actual Value 


EngValue = (ActualValue + Offeset) * Mult * Base 
Div 


The engineering value can then be displayed to the user in the terms specified within the 
Decimal Precision Instance Attribute. Use the inverse of the Scaling Formula to determine the 
actual value from the engineering value: 


Figure 5-14.5. Determining Actual Value from Engineering Value 


ActualValue = (EngValue * Div) 
Mult * Base aCe 


The extended precision scaling factor adds extended precision to the standard scaling factor. 
Use this following formula to determine the engineering value from the actual value: 


EngValue = (ActualValue + Offeset) * Mult * Base 
Div * 10 Precision 


The engineering value can then be displayed to the user in the terms specified within the 
Decimal Precision attribute. Use the inverse of the extended precision scaling formula to 
determine the actual value from the engineering value: 


= * iy * [Si 
ActualValue = (EngValue * Div * 10Precision, Offset 


Mult * Base 


For the scaling formula, the following attributes are required: 


Table 5-14.6. Scaling Formula Attributes 
Attribute Meaning 
Multiplier Value | (Mult) Multiplier value for the scaling formula. This value can be based on another parameter. 


Divisor Value (Div) Divisor value for the scaling formula. This value can be based on another parameter 
specified in the Divisor Link. 


Base Value (Base) Base value for the scaling formula. This value can be based on another parameter 
specified in the Base Link. 
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Offset Value (Offset) Offset value for the scaling formula. This value can be based on another parameter 
specified in the Offset Link. This attribute is an INT and can be negative. 

Decimal (Precision) Precision value for the scaling formula. This value cannot be based on another 

Precision parameter. 


Scaling values (multiplier, divisor, base, and offset) can also be based on other parameters. 
Scaling Links specify from which instance that scaling value is to be retrieved. If the scaling 
link attribute is set to 0, then that scaling value is a constant and not linked to another 
parameter. The following attributes specify scaling links: 


Table 5-14.7. Scaling Links 


Attribute Meaning 


Multiplier Link | Specifies the parameter instance from where the Multiplier Value is retrieved. 


Divisor Link Specifies the parameter instance from where the Divisor Value is retrieved. 
Base Link Specifies the parameter instance from where the Base Value is retrieved. 
Offset Link Specifies the parameter instance from where the Offset Value is retrieved. 


5-14.3. Common Services 


The Parameter Object provides the following Common Services: 


Service Need in 
Code Implementation 


Service Name Description of Service 


Class Instance 


OEpex | Required | Required Get_Attribute Single | Returns the contents of the specified attribute. 
Required Set_Attribute Single | Modifies an attribute value. 


Get_Attributes_All Returns a predefined listing of this objects 
attributes (See the Get_Attributes_All Response 
definition below) 


10hex | Optional 


Olnex | Optional | Conditional 


Optional for Parameter Object Stubs, required 
for Full Parameter Objects 


O5hex | Optional | n/a Reset Resets all parameter values to the factory 
default. 
IShex | Optional |n/a Restore Restores all parameter values from non-volatile 
storage. 
n/a Save Saves all parameter values to non—volatile 
storage. 


See the Appendix A for the definition of these common services. 


16hex | Optional 
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5-14.3.1. Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply data” 
portion of the Get_Attributes_All response is as follows: 


Revision (low byte) Default = 1 


1 Revision (high byte) Default = 0 

2 Max Instance (low byte) 

3 Max Instance (high byte) 

4 Parameter Class Descriptor (low byte) 

5 Parameter Class Descriptor (high byte) 

6 Configuration Assembly Instance (low byte) 
7 Configuration Assembly Instance (high byte) 
8 Native Language Default = 0 


Important: Insert default values for all unsupported attributes. 


At the Instance level, the setting of the Parameter Class Descriptor attribute dictates what 
attributes are returned by the Get Attributes All service: 


If the Parameter Class 
Descriptor Attribute: 


Then: 


does NOT have the “Supports 
Full Attributes” bit set, 


only the implemented attributes marked Stub (attribute numbers 1— 
6) are returned by the Get_Attribute_All service 


DOES have the “Supports Full 
Attributes” bit set, 


the Get_Attribute_All service returns a// implemented attributes 
(numbers 1—21) 


For Parameter object Stubs, the order of the attributes returned in the “Object/service specific 
reply data” portion (see Chapter 4 of Volume I for a description of the Service Data field) of 
the Get_Attributes_All response is as follows: 


Parameter Value (low byte) 


n Parameter Value (high byte) 
nt+1 Link Path Size 
Link Path (1st byte) 
Link Path (last byte) 


Descriptor (low byte) 


Descriptor (high byte) 
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: Data Type 
: Data Size 


For Full Parameter objects, the order of the attributes returned in the “Object/service specific 
reply data’ portion (see Chapter 4 of Volume I for a description of the Service Data field) of 
the Get_Attributes_All response is as follows: 


0 Parameter Value (low byte) 


n Parameter Value (high byte) 
nt] Link Path Size 
Link Path (1st byte) 


Link Path (last byte) 
Descriptor (low byte) 
Descriptor (high byte) 
Data Type 
Data Size 
Parameter Name String (charcount) Default = 0 


Parameter Name String (1st byte) 


Parameter Name String (last byte) 
Units String (charcount) Default = 0 
Units String (1st byte) 


Units String (last byte) 
Help String (charcount) Default = 0 
Help String (1st byte) 


Help String (last byte) 
Minimum Value (low byte) Default = 0 


Minimum Value (high byte) Default = 0 
Maximum Value (low byte) Default = 0 
Maximum Value (high byte) Default = 0 
Default Value (low byte) Default = 0 
Default Value (high byte) Default = 0 
Scaling Multiplier (low byte) Default = 1 
Scaling Multiplier (high byte) Default = 0 
Scaling Divisor (low byte) Default = 1 
Scaling Divisor(high byte) Default = 0 
Scaling Base (low byte) Default = 1 
Scaling Base (high byte) Default = 0 
Scaling Offset (low byte) Default = 0 
Scaling Offset (high byte) Default = 0 
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Multiplier Link (low byte) Default = 0 
Multiplier Link (high byte) Default = 0 
Divisor Link (low byte) Default = 0 
Divisor Link (high byte) Default = 0 
Base Link (low byte) Default = 0 
Base Link (high byte) Default = 0 
Offset Link (low byte) Default = 0 
Offset Link (high byte) Default = 0 


Decimal Precision Default = 0 


Release 1.0 
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5-14.4. Object—specific Services 


The Parameter Object provides the following Object—specific service: 


Service Need in Service Name Description of Service 
Code Implementation 


4Bhex | n/a Optional | Get_Enum_String Use this service to read 
enumerated strings from the 
Parameter Instance. See below. 


Enumerated strings are human-readable strings that describe either a bit or a value, depending 
on the parameter’s data type. 


If the parameter’s | Then the enumerated strings returned are: 


data type is: 
WORD Bit enumerated strings. 
UINT or INT Value enumerated strings. 


For example, if the parameter’s data type is WORD, requesting a Get_Enum_ String service 
with a parameter of 0 returns a SHORT_STRING that describes bit 0. Requesting a 
Get_Enum_ String service with a parameter of | returns a SHORT_STRING that describes bit 
1. 


If the parameter’s data type is UINT or INT, requesting a Get_Enum_ String service 

with a parameter of 0 returns a SHORT_STRING that describes the value of 0. Requesting a 
Get_Enum_ String service with a parameter of 1 returns a SHORT_STRING that describes the 
value of 1. 


The following parameters are defined for the Get_Enum_ String service: 


Table 5-14.8. Parameters for Get_Enum_String Request 


Name Data Type Description of Attribute Semantics of Values 
Enumerated 


USINT Number of Enumerated 
String Number String to retrieve. 


Table 5-14.9. Parameters for Get_Enum_String Response 


Name Data Type Description of Attribute Semantics of Values 


Enumerated SHORT_ Enumerated Strings Maximum number of 
String STRING characters = 16 
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5-14.5. Behavior 


The behavior of the Parameter Object is illustrated in the State Transition Diagram and State 
Event Matrix below. 


Get_Attribute_Single/ 
Set_Attribute_Single 
Get_Attributes_All 
Reset 

Restore 

Existent Save 


Get_Enum_String 


Power Up 


Event State 
Existent 


Get_Attribute Single | Validates/service the request and 


returns the appropriate response. 
Set_Attribute_Single 
Get_Attributes_All 
Reset 

Restore 

Save 


Get_Enum_ String 
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5-15. PARAMETER GROUP OBJECT 
Class Code: 10hex 


The Parameter Group Object identifies and provides access to groups of parameters in a device. 
Grouping parameters provides convenient access to related sets of parameters. 


There must be one instance of this object class for each of the device’s parameter groups. The 
instances must start at instance one and increment by one with no gaps in the instances. 


Each Parameter Group Object contains a list of member Parameter Object Instances. Use the 
Get_Attribute service to access these parameter object instances by number. 


5-15.1. Class Attributes 


Attribute Need in Access Name | DataType| Descriptionof |Semantics of Values 
ID Implementation | Rule Attribute 


This class attribute is optional and is described in Chapter 4 of this specification. 


2 Required Get Max UINT Maximum instance | The largest instance 
Instance number of an number of a created 
object currently object at this class 
created in this class | hierarchy level. 
level of the device. 


3 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


8 Optional Set i Language ID for all | O=English 
STRING accesses. | 1_French 

2=Spanish 
3=Italian 
4=German 
5=Japanese 
6=Portugese 
7=Mandarin Chinese 


5-15.2. Instance Attributes 
Attribute Need in Access Name Data Type | Description of Attribute | Semantics 
ID Implementation | Rule of Values 
1 Required Get Group Name A human-readable string Maximum 
String representing the group number of 
name (e.g., Setup, characters 
Frequency Set) =16 
2 Required Get Number of Number of parameters in 
members in group 
group 
3 Required Get lst Parameter Parameter Instance Number 
Number in 
Group 
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Attribute Need in Access Name Data Type | Description of Attribute | Semantics 
ID Implementation | Rule of Values 
4 Required Get 2nd Parameter | UINT Parameter Instance Number 
Number in 
Group 


n Required Get (n—2)th Parameter Instance Number 
Parameter 
Number in 
Group 


The Parameter Number specifies the Parameter Instance of the nth member of a particular 
Parameter Group. Perform a Get_Attribute service on this attribute to receive the Parameter 
Instance Number associated with the particular group member. 


5-15.3. Common Services 


The Parameter Group Object provides the following Common Service: 


Service Need in Service Name Service Description 
Code Implementation 
OEhex | Required | Required | Get_Attribute_Single | Returns the contents of the 
specified attribute. 


Olnex | Optional | Optional | Get_Attributes_All Returns a predefined listing of 
this objects attributes (See the 
Get_Attributes_All Response 
definition below) 

10hex Set_Attribute Single | Modifies an attribute value. 


5-15.3.1. Get Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply data” 
portion of the Get_Attributes_All response is as follows: 


Revision (low byte) Default = 1 


1 Revision (high byte) Default = 0 
2 Max Instance (low byte) 

3 Max Instance (high byte) 

4 Native Language Default = 0 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 


Group Name (charcount) 


Group Name (1st character) 
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Group Name (last character) 
N+1 Number of members in group (low byte) 
Number of members in group (high byte) 
1st Parameter number in group (low byte) 


1st Parameter number in group (high byte) 


last Parameter number in group (low byte) 


last Parameter number in group (high byte) 


5-15.4. Object—specific Services 


The Parameter Group Object provides no Object—specific services on either the Class level or 
Instance level. 


5-15.5. Behavior 


The behavior of the Parameter Group Object is illustrated in the State Transition Diagram and 
State Event Matrix below. 


Power Up 


Get_Attribute_Single/ 


Existent Set_Attribute_Single 


Table 5-15.1. State Event Matrix for Parameter Group Object 


Event State 


Existent 


Get_Attribute_Single Validates/services the request and 


returns the appropriate response. 


Set_Attribute_Single 
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5-16. GROUP OBJECT 


Class Code: 12hex 


The Group Object binds other objects, typically discrete and analog, including AIP, AOP, AIG, 
AOG, DIP, DOP, DOG, or DIG. The objects bound to the Group must support the same 
attributes and services that apply to all of the bound objects (both inputs and outputs, discrete 
and analog) in a product. 


You must establish the list of groups and/or points bound to the Group at power-up, as the 
Binding List is static and a Get—only attribute of the Group. 


Use the Group Object: 


e when many attributes are shared among many analog and/or discrete input and output 
points and/or groups. 


e tomore efficiently access data by supporting services that may affect all members of the 


group. 


a IS 


wae) 


es ay . 
hb 6h 


Need in Access Name Data Type Description of 
Implementation | Rule Attribute 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Semantics of 
Values 


Number 
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5-16.2. Instance Attributes 


Attribute Need in Access Name Data Type Description of Semantics of 
ID Implementation | Rule Attribute Values 
1 Optional Number of USINT Number of attributes 
Attributes supported by the group 
2 Attribute List | ARRAY of List of attributes 
| 


USINT supported 


Number of Number of points in a 
Bound group 
Instances 


4 Optional Binding List of instances in 
group 
a ns 
5 Optional Status Group is operating 0=go0d; 
without alarms or faults | 1=alarm state 
6 Optional Owner - Vendor ID of group’s 
Vendor ID owner 


Get 
Get 
Get 
Get 
Get 
Get 

et 


ee 


5-16.3. Common Services 


Owner - Serial 32-bit serial number of 
Number group’s owner 


The Group Object provides the following Common Services: 


Service Need in Service Name Description of Service 
Code Implementation 


OEpex | Optional* | Required | Get_Attribute_Single | Returns the contents of the 
specified attribute. 


Olnex |Optional | Optional | Get_Attributes_All Returns a predefined listing of 
this objects attributes (See the 
Get_Attributes_All Response 
definition below) 


*The Get_Attribute_ Single service is REQUIRED if any attributes are implemented. 


5-16.3.1. Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply 
data” portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 


Revision (low byte) Default = 1 
Revision (high byte) Default = 0 


Max Instance (low byte) Default = 0 
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Max Instance (high byte) Default = 0 
Max ID Number of Class Attributes (low byte) Default = 0 


Max ID Number of Class Attributes (high byte) Default = 0 


Max ID Number of Instance Attributes (low byte) Default = 0 


NLD [Tn [HR [w 


Max ID Number of Instance Attributes (high byte) Default = 0 


Important: Insert default values for all unsupported attributes. 


Chapter 5: Object Library 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 


data” portion of the Get_Attributes_All response is as follows: 


Number of Attributes Default = 0 


Attribute List (attribute #1) 


n Attribute List (attribute #m) 


n+] Number of Bound Instances Default = 0 
Binding : Class ID #1 (low byte) 
Binding : Class ID #1 (high byte) 
Binding : Instance ID #1 (low byte) 


Binding : Instance ID #1 (high byte) 


Binding : Class ID #m (low byte) 
Binding : Class ID #m (high byte) 
Binding : Instance ID #m (low byte) 


Binding : Instance ID #m (high byte) 


Status 
Default = 0 


Owner Vendor ID (low byte) Default = 
Owner Vendor ID (high byte) Default = 0 
Owner Serial Number (low byte) Default = 0 
Owner Serial Number Default = 0 
Owner Serial Number Default = 0 


Owner Serial Number (high byte) Default = 0 


Important: Insert default values for all unsupported attributes. 
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5-16.4. 


5-16.5. 


5-90 


Important: If the instance attribute Number of Attributes” is not supported, the default value 
of zero is to be inserted in its place and no members of the ’Attribute List” attribute will 
follow. 


Important: If the instance attribute Number of Bound Instances” is not supported, the default 
value of zero is to be inserted into the response byte array and no Binding data will follow. 


Object—specific Services 


The Group Object provides no Object—specific services. 


Behavior 


The primary purpose of the Group Object is to bind Analog and Discrete Groups and/or Points. 
An attribute of the Group will modify the behavior or report additional status information of all 
objects bound to the group. 


The State Transition Diagram (STD) below illustrates the Behavior of a Group Object. The 
states shown are equivalent to the following: 
This state Is equivalent to 
Non-Existent a module without power 


a module that has an unrecoverable fault (e.g. processor 
watchdog timeout) 


a major reconfiguration of the module (e.g. NVS Update) 


Binding when groups and/or points are added or bound to the 
Group (executed as part of Power Up cycle) 


Run the point at which Get and Set attribute services can be 
used to access the attributes of the Group Object 


Non-Existent ———__ Power Down 
(any state) 


Power Up 


Binding 


Binding 
Established 


Attribute Access Rules 
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Release 1.0 


All attributes are gettable or settable according to their attribute access rules, but only in the 
Run state. 


The Status attribute is simply a logical OR of all possible failure or alarm conditions for all 
points bound to the group. 


Status 
—— Failures or Alarms 
for all points 


The Owner Vendor ID and Owner Serial Number are included in the object definition but their 
use is TBD. 
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5-17. DISCRETE INPUT GROUP OBJECT 
Class Code: 1Dhex 
The Discrete Input Group (DIG) Object binds a group of discrete input points in a module. All 
points bound to the group share all attributes contained in the group. If an attribute is shared 
(points have the same attributes and the same attribute values) across more than one Discrete 
Input Point (DIP), then that attribute can be contained in a Discrete Input Group. A Discrete 


Input Point can be bound to more than one Discrete Input Group. 


You must establish the list of discrete input points bound to the group at power-up, as the 
binding list is static and is a Get—only attribute of the group. 


Use the Discrete Input Group Object: 


e when a single attribute is shared among many input points. 


e tomore efficiently access data (services that affect all members of a group 
can be supported by the DIG). 


aN 


5-17.1. Class Attributes 


Need in Access Name Data Type Description of 
Implementation | Rule Attribute 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Semantics of 
Values 


5-17.2. Instance Attributes 
Attr Need in Access Name Data Type Description of Semantics of 
ID | Implementation | Rule Attribute Values 
1 Optional Get Number of Number of attributes 
Attributes supported by the 
device 
2 | Optional Get Attribute List | ARRAY of List of attributes 
USINT supported by the 
device 
3 | Optional Get Number of USINT Number of points 
Bound bound to this group 
Instances 
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Attr Need in Access Name Data Type Description of Semantics of 
ID | Implementation | Rule Attribute Values 

4 | Optional Get Binding ARRAY of: _ | List of all points Class DIP 

bound to this group Instance #X 
Class DIP 
Instance #Y... 
UINT Instance ID 

5 | Optional Get Status BOOL Status for all discrete |0=OK 
input points in the 1 = Product 
group specific alarm or 

status 

6 Optional Set Off_On Delay filter time for off to on | The default value 
transition is 0. 
0 - 65,535 
microseconds | 

7 | Optional Set On_Off Delay filter time for on to off | The default value 
transition is 0. 
0 - 65,535 
microseconds 2 


'The input must be on for the amount of filter time specified by the OFF_ON DELAY attribute before the ON 
state is recorded in the VALUE attribute. 

2The input must be off for the amount of filter time specified by the ON_OFF DELAY attribute before the OFF 
state is recorded in the VALUE attribute. 


5-17.3. Common Services 


The Discrete Input Group Object provides the following Common90 Services: 


Service Need in Service Name Description of Service 
Code Implementation 


OEpex | Conditional* | Required | Get_Attribute_Single | Returns the contents of the 
specified attribute. 


Olhex | Optional Optional | Get_Attributes_All Returns a predefined listing of 
this objects attributes (See the 
Get_Attributes_All Response 
definition below) 


10hex Set_Attribute Single | Modifies an attribute value. 


O2hex | n/a Optional | Set_Attributes_All Modifies the contents of the 
attributes of the class or object 


*The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 


5-17.3.1.. Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes_All response is as follows: 
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Revision (low byte) Default = 1 


1 Revision (high byte) Default = 0 

2 Max Instance (low byte) Default = 0 

3 Max Instance (high byte) Default = 0 

4 Number of Instances (low byte) Default = 0 

5 Number of Instances (high byte) Default = 0 

6 Max ID Number of Class Attributes (low byte) Default = 0 

7 Max ID Number of Class Attributes (high byte) Default = 0 
8 Max ID Number of Instance Attributes (low byte) Default = 0 
9 Max ID Number of Instance Attributes (high byte) Default = 0 


Important: Insert default values for all unsupported attributes. 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes_All response is as follows: 


Number of Attributes Default = 0 


Attribute List (attribute #1) 


n Attribute List (attribute #m) 


n+] Number of Bound Instances Default = 0 
Binding : Instance ID #1 (low byte) 


Binding : Instance ID #1 (high byte) 


Binding : Instance ID #m (low byte) 


Binding : Instance ID #m (high byte) 


Status 
Default = 
0 


Off On Delay (low byte) Default = 0 
Off On Delay (high byte) Default = 0 
On_Off Delay (low byte) Default = 0 


On_Off Delay (high byte) Default = 0 
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Important: Insert default values for all unsupported attributes. 


Important: If the instance attribute Number of Attributes” is not supported, the default value 
of zero is to be inserted in its place and no members of the ’Attribute List” attribute will 
follow. 


Important: If the instance attribute Number of Bound Instances” is not supported, the default 
value of zero is to be inserted into the response byte array and no Binding data will follow. 


5-17.3.2.  Set_Attributes_All Request 
No settable attributes currently exist at the Class level for the Discrete Input Group Object. 


At the Instance level, the order of attributes passed in the “Object/service specific request 
data” portion of the Set_Attributes_All request is as follows: 


Off On Delay (low byte) Default = 


1 Off _On Delay (high byte) Default = 0 
2 On_Off Delay (low byte) Default = 0 
3 On_Off Delay (high byte) Default = 0 


Important: The Set_Attributes_All service is to be supported only if all settable attributes 
shown above are implemented as settable. 


5-17.4. Object—specific Services 


The Discrete Input Group Object does not support any Object-specific services. 


5-17.5. Behavior 


The primary purpose of the DIG is to bind discrete input points. 


An attribute of the DIG will modify the behavior or report additional status information of all 
DIPs bound to the group. 


The State Transition Diagram below provides a graphical description of the events and 
corresponding state transitions. A subset of the states and events may be supported in an 


application, but the behavior must be consistent. 


The states shown are equivalent to the following: 
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This state 


Non-Existent 


Binding 


Run 


Volume 1: CIP Common Specification 


Is equivalent to 
a module without power 


a module that has an unrecoverable fault (e.g. processor 
watchdog timeout) 


a major reconfiguration of the module (e.g. NVS Update) 


when discrete input points are added or bound to the Discrete 
Input Group (executed as part of Power Up cycle) 


the point at which Get and Set attribute services can be used to 
access the attributes of the Group Object 


(any state) 


Power Up 


Binding 
Established 


Attribute Access Rules 


All attributes are gettable or settable according to their attribute access rules, but only in the 


Run state. 


The Status attribute is simply a logical OR of all possible failure or alarm conditions for all 


points bound to the group. 


Status 
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for all points 
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5-18. DISCRETE OUTPUT GROUP OBJECT 
Class Code: 1Ehex 
The Discrete Output Group (DOG) Object binds a group of discrete output points in a module. 
All points bound to the group share all attributes contained in the group. If an attribute is 
shared across more than one Discrete Output Point (DOP), then it can be contained in a 
Discrete Output Group. A Discrete Output Point can also be bound to more than one Discrete 


Output Group. 


You must establish the list of discrete output points bound to the group at power-up, as the 
binding list is static and is a Get—only attribute of the group. 


Use the Discrete Output Group Object: 


e when a single attribute is shared among many output points. 


e tomore efficiently access data (services that affect all members of a group can be 
supported by the DOG). 


Zod 


5-18.1. Class Attributes 


Need in Access Name Data Type | Description of Attribute 
Implementation | Rule 


These class attributes are optional and are described in Chapter 4 of this specification. 


Attribute 
ID 


Semantics of 
Values 


5-18.2. Instance Attributes 


Attr ID Need in Access Name Data Type | Description of Attribute | Semantics of 
Implementation | Rule Values 
1 Optional Get Number of USINT Number of attributes 
Attributes supported by the device 
2 Optional Get Attribute List | ARRAY of | List of attributes 
USINT supported by the device 
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Attr ID Need in Access Name Data Type | Description of Attribute | Semantics of 
Implementation | Rule Values 
3 Optional Number of Number of points bound 
Bound to this group 
Instances 


4 Optional Binding List of all points bound to 
this 4 


5 a Get Status BOOL Status a all discrete 0=OK 
output points in the group | 1 = Product 
specific alarm 
or status 
6 Required Set Command BOOL Changes state of all DOPs | 0=idle 
in group to Idle Mode or | 1=run 
Run Mode 
7 Optional Fault State BOOL State of output after 0=Fault Value 
recoverable failure attribute; 
1=hold last 
state 
8 Optional Fault Value BOOL User-defined value for 0=off; 
use with Fault State 1=on 
attribute 
9 Optional Idle State BOOL State of output during idle | 0=Idle Value 
attribute; 
1=hold last 
state 


10 Optional Idle Value BOOL User-defined value for use | 0=off; 
with Idle State attribute 1=on 


5-98 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification 


5-18.3. 


5-18.3.1. 


Release 1.0 


Common Services 


The Discrete Output Group Object provides the following Common Services: 


Service Need in Service Name Description of Service 
Code Implementation 


OEpex | Conditional* | Required | Get_Attribute_Single | Returns the contents of the 
specified attribute. 


Olnex | Optional Optional | Get_Attributes_All Returns a predefined listing 
of this objects attributes (See 
the Get_Attributes_All 
Response definition below) 


10hex Set_Attribute_Single | Modifies an attribute value. 


02hex n/a Optional | Set_Attribute_All Modifies the contents of the 
attributes of the class or 
object 


*The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 


See the Appendix A for definitions of these services. 


Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes_All response is as follows: 


0 Revision (low byte) Default = 1 

1 Revision (high byte) Default = 0 

2 Max Instance (low byte) Default = 0 

3 Max Instance (high byte) Default = 0 

6 Max ID Number of Class Attributes (low byte) Default = 0 

7 Max ID Number of Class Attributes (high byte) Default = 0 
8 Max ID Number of Instance Attributes (low byte) Default = 0 
9 Max ID Number of Instance Attributes (high byte) Default = 0 


Important: Insert default values for all unsupported attributes. 
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5-18.3.2. 


5-100 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 


Number of Attributes Default = 0 


Attribute List (attribute #1) 


n Attribute List (attribute #m) 


n+l Number of Bound Instances Default = 0 
Binding : Instance ID #1 (low byte) 
Binding : Instance ID #1 (high byte) 
Binding : Instance ID #m (low byte) 


Binding : Instance ID #m (high byte) 


Status 
Default = 0 


Fault State 
Default = 0 
Fault Value 
Default = 0 
Idle State 
Default = 0 
Idle 
Value 
Default = 0 


Important: Insert default values for all unsupported attributes. 


Important: If the instance attribute Number of Attributes” is not supported, the default value 
of zero is to be inserted in its place and no members of the ’Attribute List” attribute will 
follow. 


Important: If the instance attribute Number of Bound Instances” is not supported, the default 
value of zero is to be inserted into the response byte array and no Binding data will follow. 


Set_Attributes_All Request 
No settable attributes currently exist at the Class level for the Discrete Output Group Object. 


At the Instance level, the order of attributes passed in the “Object/service specific request 
data” portion 
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5-18.4. 


5-18.5. 


Release 1.0 


Important: The Set_Attributes_All service is to be supported only if all settable attributes 
shown above are implemented as settable. 


Object-specific Services 


The Discrete Output Group Object provides no Object—specific services. 


Behavior 
The primary purpose of the Discrete Output Group Object is to bind discrete output points. 


An attribute of the DOG will modify the behavior or report additional status information of all 
DOPs bound to the group. 


The State Transition Diagram below provides a graphical description of the events and 
corresponding state transitions. A subset of the states and events may be supported in an 
application, but the behavior must be consistent. 


The states shown are equivalent to the following: 


This state Is equivalent to 
Non-Existent a module without power 


a module that has an unrecoverable fault (e.g. processor 
watchdog timeout) 


a major reconfiguration of the module (e.g. NVS Update) 


Binding when discrete output points are added or bound to the Discrete 
Output Group (executed as part of Power Up cycle) 


Run the point at which Get and Set attribute services can be used to 
access the attributes of the Group Object 
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5-102 


Non-Existent —a Power Down 


(any state) 
Power Up 


Binding 
Established 


Attribute Access Rules 


All attributes are gettable or settable according to their attribute access rules, but only in the 
Run state. 


The Status attribute is simply a logical OR of all possible failure or alarm conditions for all 
points bound to the group. 
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5-19. 


5-19.1. 


Release 1.0 


DISCRETE GROUP OBJECT 

Class Code: 1Fhex 
The Discrete Group (DG) Object binds other discrete objects including DIP, DOP, DIG or 
DOG. The objects (both input and output) bound to the Discrete Group must support the same 


attributes and services. 


You must establish the list of discrete groups and/or points bound to the Discrete Group at 
power-up, as the Binding List is static and a Get—only attribute of the Discrete Group. 


Use the Discrete Group Object: 


e when a single attribute is shared among many discrete input and output points 
and/or groups. 


e to more efficiently access data (services that affect all members of the group 


can be supported by the DG). 


For example: 
The Discrete Group Object could be used when a module contains 4 DIPs and 4 DOPs; the 
DIPs are grouped into a DIG to share a common attribute, and the DOPs are grouped into a 


DOG to share a common output behavior. 


You want all points to share a common status. The DG has the common attribute Status and 
binds the DIG and DOG, which in turn bind the individual points. 


Class Attributes 


Attribute Need in Access Name Data Type Description of Semantics of 
ID Implementation | Rule Attribute Values 


These class attributes are optional and are described in Chapter 4 of this specification. 
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5-19.2. Instance Attributes 


Attribute Need in Access Name Data Type Description of Semantics of 
ID implementation | Rule Attribute Values 


1 Optional Get Number of Number of 
Attributes attributes 
supported by the 
group 
2 Optional Get Attribute List | ARRAY of List of attributes 
USINT supported 
3 Optional Get Number of Number of points 
Bound in a group 
Instances 
4 Optional Binding ARRAY of List of all 
STRUCT: instances cian 
— Class ID UINT 


> am Status BOOL Group is 0=go0d; 
operating without | 1=alarm state 
alarms or faults 


5-19.3. Common Services 


The Discrete Group Object provides the following Common Services: 


Service | Need in Implementation Service Name Description of Service 


Code 
OEnex Get_Attribute Single | Returns the contents of the specified attribute. 
Olhex | Optional Optional | Get_Attributes_All Returns a predefined listing of this objects 
attributes (See the Get_Attributes_All Response 
definition below) 
*The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 
5-19.3.1. Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes_All response is as follows: 


Revision (low byte) Default = 1 


1 Revision (high byte) Default = 0 

2 Max Instance (low byte) Default = 0 

3 Max Instance (high byte) Default = 0 

6 Max ID Number of Class Attributes (low byte) Default = 0 

7 Max ID Number of Class Attributes (high byte) Default = 0 
8 Max ID Number of Instance Attributes (low byte) Default = 0 
9 Max ID Number of Instance Attributes (high byte) Default = 0 
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5-19.4. 


5-19.5. 


Release 1.0 


Important: Insert default values for all unsupported attributes. 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 


Number of Attributes Default = 0 


Attribute List (attribute #1) 


n Attribute List (attribute #m) 


nt+1 Number of Bound Instances Default = 0 
Binding : Class ID #1 (low byte) 
Binding : Class ID #1 (high byte) 
Binding : Instance ID #1 (low byte) 


Binding : Instance ID #1 (high byte) 
Binding : Class ID #m (low byte) 
Binding : Class ID #m (high byte) 

Binding : Instance ID #m (low byte) 


Binding : Instance ID #m (high byte) 


; Status 
Default = 0 


Important: Insert default values for all unsupported attributes. 


Important: If the instance attribute ” Number of Attributes” is not supported, the default value 
of zero is to be inserted in its place and no members of the ’Attribute List” attribute will 
follow. 


Important: If the instance attribute Number of Bound Instances” is not supported, the default 
value of zero is to be inserted into the response byte array and no Binding data will follow. 


Object—specific Services 
The Discrete Group Object provides no Object—specific services. 
Behavior 


The primary purpose of the Discrete Group is to bind Discrete Groups and/or Points. 


An attribute of the DG modifies the behavior or reports additional status information of all 
objects bound to the group. 
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The State Transition Diagram below illustrates the behavior of a Discrete Group. 


This state Is equivalent to 
Non-Existent a module without power 
a module that has an unrecoverable fault (e.g. processor watchdog timeout) 
a major reconfiguration of the module (e.g. NVS Update) 


Binding when the discrete groups and/or points are added or bound to the Discrete 
Group (executed as part of Power Up cycle) 


Run the point at which Get and Set attribute services can be used to access the 
attributes of the Discrete Group 


Non-Existent Power Down 
[sve | <— lany state 

| Power Up 
[ans | 


Binding 
Established 
Run 


Attribute Access Rules 


All attributes are gettable or settable according to their attribute access rules, but only in the 
Run state. 


The Status attribute is simply a logical OR of all possible failure or alarm conditions for all 
points bound to the group. 


Status : 
Failures or Alarms 


for all points 
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5-20. 


5-20.1. 


5-20.2. 


Release 1.0 


ANALOG INPUT GROUP OBJECT 

Class Code: 20hex 
The Analog Input Group Object (AIG) binds a group of analog input points in a module. All 
points bound to the group share all attributes contained in the group . If an attribute is shared 
(points have the same attributes AND the same attribute values) across more than one Analog 
Input Point (AIP), then that attribute can be contained in an Analog Input Group. An Analog 


Input Point can be bound to more than one Analog Input Group. 


You must establish the list of analog input points bound to the group at power-up, as the 
binding list is static and is a Get—only attribute of the group. 


Use the Analog Input Group Object: 


e when a single attribute is shared among many input points. 


e tomore efficiently access data (services that affect all members of the group can be 
supported by the AIG). 


5 > 


Class Attributes 


Need in Access Name Data Type Description of 
Implementation | Rule Attribute 


These class attributes are optional and are described in Chapter 4 of this specification. 


Attribute 
ID 


Semantics of Values 


Instance Attributes 


Attr ID Need in Access Name Data Type | Description of Semantics of 
implementation | Rule Attribute Values 
1 Optional Get Number of Number of 
Attributes attributes 
supported by the 
group 
2 Optional Get Attribute ARRAY of | List of attributes 
List USINT supported 
3 Optional Get Number of Bound | USINT Number of points 
Instances in a group 
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Attr ID Need in Access Name Data Type | Description of Semantics of 
implementation | Rule Attribute Values 
4 Optional Get Bound Instances | ARRAY of | List of all points 
UINT bound to this group 
5 Optional Get Status BOOL Group is operating | 0=good; 
without alarms or | 1=alarm state 
faults 
6 Optional Get Owner - Vendor |UINT Vendor ID of 
ID group’s owner 


7 Optional Get Owner - Serial 32-bit serial 
Number number of group’s 
owner 
8 Optional Set Value Data Type Determines the 0=INT 
data type of AIP’s | 1 =REAL 
Value 2 = USINT 
3 = SINT 
4=DINT 
5 = LINT 
6 = UINT 
7 = UDINT 
8 = ULINT 
9 = LREAL 


100=vendor specific 


9 [Reservedforcip| | 
Set 


10 Optional Temp Mode BOOL Temperature scale | 0 = Celsius 
to use when 1 = Fahrenheit 
reporting a 
temperature value 


5-20.3. Common Services 


The Analog Input Group Object provides the following Common Services: 


Service | Need in Implementation Service Name Description of Service 
Code 


OEnex | Conditional! | Required | Get_Attribute_Single | Returns the contents of the specified attribute. 


10hex Required Set_Attribute Single | Modifies an attribute value. 

Olnex | Optional Optional | Get_Attributes_All Returns a predefined listing of this objects 
attributes (See the Get_Attributes_All Response 
definition below) 

O2hex | n/a Optional | Set Attributes All Modifies the contents of the attributes of the 
class or object. 


'The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 


2The Set_Attribute_Single service is required only if Instance Attributes #8 and/or #10 are implemented. 


See the Appendix A for definitions of these services. 
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5-20.3.1. 


Release 1.0 


Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes_All response is as follows: 
0 Revision (low byte) Default = 1 
Revision (high byte) Default = 0 
Max Instance (low byte) Default = 0 
Max Instance (high byte) Default = 0 
Max ID Number of Class Attributes (low byte) Default = 0 
Max ID Number of Class Attributes (high byte) Default = 0 
Max ID Number of Instance Attributes (low byte) Default = 0 
Max ID Number of Instance Attributes (high byte) Default = 0 


NALA] ATR [ wl NM]re 


Important: Insert default values for all unsupported attributes. 


At the Instance level, the order of the attributes returned in the ““Object/service specific reply 
data” portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 


Number of Attributes Default = 0 
Attribute List (attribute #1) 


Attribute List (attribute #m) 
Number of Bound Instances Default = 0 
Binding : Instance ID #1 (low byte) 
Binding : Instance ID #1 (high byte) 


Binding : Instance ID #m (low byte) 
Binding : Instance ID #m (high byte) 


Status 
Default = 
0 


Owner Vendor ID (low byte) Default = 
Owner Vendor ID (high byte) Default = 
Owner Serial Number (low byte) Default = 0 
Owner Serial Number Default = 0 
Owner Serial Number Default = 0 
Owner Serial Number (high byte) Default = 0 
Value Data Type Default = 


Temp 
Mode 
Default = 
0 


Important: Insert default values for all unsupported attributes. 


Important: If the instance attribute Number of Attributes” is not supported, the default value 
of zero is to be inserted in its place and no members of the ”Attribute List” attribute will 
follow. 
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5-20.3.2. 


5-20.4. 


5-20.5. 
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Important: If the instance attribute Number of Bound Instances” is not supported, the default 
value of zero is to be inserted into the response byte array and no Binding data will follow. 


Set_Attributes_All Request 


No settable attributes currently exist at the Class level for the Analog Input Group Object. 


At the Instance level, the order of attributes passed in the “Object/service specific request 
data” portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Set_Attributes_All request is as follows: 


Important: The Set_Attributes_All service is to be supported only if all settable attributes 
shown above are implemented as settable. 


Object-specific Services 
The Analog Input Group Object provides no Object—specific services. 
Behavior 


The primary purpose of the Analog Input Group Object is to bind analog input points. 


An attribute of the AIG modifies the behavior or reports additional status information of all 
AIPs bound to the group. 


The State Transition Diagram below provides a graphical description of the events and 
corresponding state transitions. A subset of the states and events may be supported in an 
application, but the behavior must be consistent. 


The states shown are equivalent to the following: 
This state Is equivalent to 
Non-Existent a module without power 


a module that has an unrecoverable fault (e.g. processor 
watchdog timeout) 


a major reconfiguration of the module (e.g. NVS Update) 


Binding when analog input points are added or bound to the 
Analog Input Group (executed as part of Power Up 
cycle) 

Run the point at which Get and Set attribute services can be 


used to access the attributes of the Group Object 
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2 ans ri 
(any state) 


Power Up 


Binding 
Established 


Attribute Access Rules 
All attributes are gettable or settable according to their attribute access rules. 


The Status attribute is simply a logical OR of all possible failure or alarm conditions for all 
points bound to the group. 


tatu: 
: a Failures or Alarms 
for all points 


The Value Data Type attribute determines the data type to be used by the attribute Value (and 
perhaps other attributes as well). If Value Data Type is not used, then Value defaults to INT. 
Value (and other attributes) may behave as REAL, USINT, or any other data type based upon 
the definition of Value Data Type, which ultimately provides the ability for the analog point to 
be defined in any length necessary. 


The Owner Vendor ID and Owner Serial Number are included in the object definition but 
their use is TBD. 


The attribute Temp Mode is a Boolean data type that governs the behavior of the Value 
attribute of the AIP when returning a temperature. The temperature is returned in either Celcius 
or Fahrenheit according to the current value of the Temp Mode attribute. AIP values are 
typically returned as a temperature for thermocouple and RTD channels when linearization is 
turned on. 
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5-21. ANALOG OUTPUT GROUP OBJECT 


Class Code: 21hex 


The Analog Output Group Object (AOG) binds a group of analog output points in a module. 
All points bound to the group share all attributes contained in the group. If an attribute is 
shared (points have the same attributes and the same attribute values) across more than one 
Analog Output Point (AOP), then that attribute can be contained in an Analog Output Group. 
An Analog Output Point can be bound to more than one Analog Output Group. 


You must establish the list of analog output points bound to the group at power-up, as the 
binding list is static and is a Get—only attribute of the group. 


Use the Analog Output Group Object: 


e when a single attribute is shared among many input points. 


e tomore efficiently access data (services that affect all members 
of a group can be supported by the AOG). 


5 > 


5-21.1. Class Attributes 


Need in Access Name Data Type Description of 
Implementation | Rule Attribute 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Number Semantics of Values 


5-21.2. Instance Attributes 


Implementation Rule Attribute Values 
7 
Attributes supported by the group 
Get 


3 Optional Number of USINT Number of bindings in 
Bound the group 
Instances 
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Implementation Rule Attribute Values 
4 Optional Get Bound ARRAY of | List of all points 
Instances UINT bound to this group 
Optional Get Status BOOL Group is operating 0=good; 
without alarms or 1=alarm state 
faults 
Optional Get Owner - UINT Vendor ID of group’s 
Vendor ID owner 
7 Optional Get Owner - UDINT 32-bit serial number 
Serial of group’s owner 
Number 


8 Optional Set Value Data USINT Determines the data 0=INT 
Type type of any bound 1 =REAL 
Values 2 = USINT 
3 = SINT 
4=DINT 
5 =LINT 
6 = UINT 
7=UDINT 
8 = ULINT 
9 =LREAL 
100=vendor 
specific 


9 Required Set Command BOOL Changes state of AOP | 0 = idle 
to Idle Mode or Run 1=run 
Mode 
10 Optional Set Fault State BOOL State of output after 0=Fault Value 
recoverable failure attribute; 
1=hold last state 
11 Optional Set Fault Value INT or User-defined value for 
based on use with Fault State 
attribute 8 | attribute 
12 Optional Set Idle State State of output during | 0=Idle Value 
idle attribute; 
1=hold last state 
13 Optional Set Idle Value INT or User-defined value for 
based on use with Idle State 
attribute 8 | attribute 


5-21.3. Common Services 


n 


an 


The Analog Output Group Object provides the following Common Services: 


Service | Need in Implementation Description of Service 
Code 


Class nstance 


I 
OEhex | Conditional! | Required | Get_Attribute_Single | Returns the contents of the 
specified attribute. 


10hex Required Set_Attribute Single | Modifies an attribute value. 


Olhex | Optional Optional | Get_Attributes_ All Returns a predefined listing 
of this objects attributes (See 
the Get_Attributes_All 
Response definition below) 


O2hex n/a Optional | Set_Attributes_All Modifies the contents of the 
attributes of the class or 
object. 


'The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 


2The Set Attribute Single service is required only if Instance Attribute #8 is implemented. 
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See Appendix A for definitions of these services. 
5-21.3.1. Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes All response is as follows: 


Byte Bit 0 
0 Revision (low byte) Default = 1 
Revision (high byte) Default = 0 
Max Instance (low byte) Default = 0 
Max Instance (high byte) Default = 0 
Max ID Number of Class Attributes (low byte) Default = 0 
Max ID Number of Class Attributes (high byte) Default = 0 
Max ID Number of Instance Attributes (low byte) Default = 3 
Max ID Number of Instance Attributes (high byte) Default = 0 


NAD] NA], BR]WlLNm]e 


Important: Insert default values for all unsupported attributes. 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes_All response is as follows: 


Command 


Number of Attributes Default = 0 


Attribute List (attribute #1) 


n Attribute List (attribute #m) 


n+l Number of Bound Instances Default = 0 
Binding : Instance ID #1 (low byte) 
Binding : Instance ID #1 (high byte) 
Binding : Instance ID #m (low byte) 


Binding : Instance ID #m (high byte) 


Status 
eal = 


Owner Vendor ID (low byte) Default = 
Owner Vendor ID (high byte) Default = 0 
Owner Serial Number (low byte) Default = 0 
Owner Serial Number Default = 0 
Owner Serial Number Default = 0 


Owner Serial Number (high byte) Default = 0 
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Value Data Type Default = 


Fault 
State 
ae = 


Fault Value (low byte) Default = 


Fault Value (high byte) Default = 


Idle State 
aa = 


Idle Value (low byte) Default = 
Idle Value (high byte) Default = 0 
Important: Insert default values for all unsupported attributes. 


Important: If the instance attribute ’ Number of Attributes” is not supported, the default value 
of zero is to be inserted in its place and no members of the ”Attribute List” attribute will 
follow. 


Important: If the instance attribute Number of Bound Instances” is not supported, the default 
value of zero is to be inserted into the response byte array and no Binding data will follow. 


5-21.3.2. Set_Attributes_All Request 
No settable attributes currently exist at the Class level for the Analog Output Group Object. 


At the Instance level, the order of attributes passed in the “Object/service specific request 
data” portion of the Set_Attributes_All request is as follows: 


=0 
| oo fT oT Idle State 


Idle Value (low byte) Default = 0 
Idle Value (high byte) Default = 0 


Important: The Set_Attributes_All service is to be supported only if all settable attributes 
shown above are implemented as settable. 


5-21.4. Object—specific Services 


The Analog Output Group Object provides no Object-specific services. 
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5-21.5. Behavior 


The primary purpose of the Analog Output Group is to bind Analog Output Points. 


An attribute of the AOG will modify the behavior or report additional status information of all 
AOPs bound to the group. 


The State Transition Diagram below provides a graphical description of the events and 
corresponding state transitions. A subset of the states and events may be supported in an 
application, but the behavior must be consistent. 


The states shown are equivalent to the following: 
This state Is equivalent to 
Non-Existent a module without power 


a module that has an unrecoverable fault (e.g. processor 
watchdog timeout) 


a major reconfiguration of the module (e.g. NVS Update) 


Binding when analog output points are added or bound to the Analog 
Output Group (executed as part of Power Up cycle) 


Run the point at which Get and Set attribute services can be used to 
access the attributes of the Group Object 


— pale si 
(any state) 


Power Up 


Binding 
Established 


Attribute Access Rules 


All attributes are gettable or settable according to their attribute access rules, but only in the 
Run state. 


The Status attribute is simply a logical OR of all possible failure or alarm conditions for all 
points bound to the group. 
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Status 
——_ Failures or Alarms 
for all points 


The Value Data Type attribute determines the data type to be used by the attribute Value (and 
perhaps other attributes as well). If Value Data Type is not used, then Value defaults to INT. 
Value (and other attributes) may behave as REAL, USINT, or any other data type based upon 
the definition of Value Data Type, which ultimately provides the ability for the analog point to 
be defined in any length necessary. 


The Owner Vendor ID and Owner Serial Number are included in the object definition but 
their use is TBD. 
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5-22. 


5-22.1. 


5-22.2. 
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ANALOG GROUP OBJECT 

Class Code: 22hex 
The Analog Group (AG) Object binds other analog objects including AIP, AOP, AIG or AOG. 
The objects (both inputs and outputs) bound to the Analog Group must support the same 


attributes and services. 


You must establish the list of analog groups and/or points bound to the Analog Group at 
power-up, as the Binding List is static and a Get—only attribute of the Analog Group. 


Use the Analog Group Object: 


e when a single attribute is shared among many analog input and output 
points and/or groups. 


e tomore efficiently access data (services that affect all members of 
a group and/or points can be supported by the AG). 


Class Attributes 


Need in Access Name Data Description of 
Implementation | Rule Type Attribute 


1 thru7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Semantics of 
Values 


Number 


Instance Attributes 
Need in Access Name Data Description of 
Implementation | Rule Type Attribute 
Optional Get Number of USINT Number of attributes 
Attributes supported by the group 
Optional Attribute List |ARRAY | List of attributes 
of USINT | supported 


Optional Number of USINT Number of points in a 
Bound group 


Attr ID Semantics of 


Values 


Instances 
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| 


Binding ARRAY _ | List of all instances in 
of 


group 
STRUCT: 


5 Optional Get Status BOOL Group is operating 0=good; 
without alarms or faults | 1=alarm state 
6 Optional Get Owner - UINT Vendor ID of group’s 
Vendor ID owner 
ii Optional Get Owner - Serial | UDINT 32-bit serial number of 
Number group’s owner 


Optional Value Data BYTE Determines the data 0=INT 

type of all bound 1 =REAL 
object’s Value which 2 = USINT 
propagate through 3 = SINT 
another binding if 4=DINT 
groups are bound to AG | 5 = LINT 

6 = UINT 

7 =UDINT 

8 = ULINT 

9 =LREAL 

100 = vendor 

specific 


5-22.3. Common Services 
The Analog Group Object provides the following Common Services: 


Service | Need in Implementation Description of Service 
Code 


OEhex | Conditional! | Required |Get_Attribute Single | Returns the contents of the 
specified attribute. 
10hex Required Set_Attribute_Single | Modifies an attribute value. 


Olnex | Optional Optional | Get_Attributes_All Returns a predefined listing 
of this objects attributes (See 
the Get_Attributes_All 
Response definition below) 


'The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 


2The Set_Attribute_Single service is required only if Instance Attribute #8 is implemented. 


5-22.3.1. Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes_All response is as follows: 


Revision (low byte) Default = 1 
Revision (high byte) Default = 0 


Max Instance (low byte) Default = 0 
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3 Max Instance (high byte) Default = 0 
Max ID Number of Class Attributes (low byte) Default = 0 
Max ID Number of Class Attributes (high byte) Default = 0 
Max ID Number of Instance Attributes (low byte) Default = 0 


NLA] ays 


Max ID Number of Instance Attributes (high byte) Default = 0 


Important: Insert default values for all unsupported attributes. 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion (see Chapter 4 of Volume I for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 


Number of Attributes Default = 0 


Attribute List (attribute #1) 


n Attribute List (attribute #m) 


n+] Number of Bound Instances Default = 0 
Binding : Class ID #1 (low byte) 
Binding : Class ID #1 (high byte) 
Binding : Instance ID #1 (low byte) 


Binding : Instance ID #1 (high byte) 


Binding : Class ID #m (low byte) 
Binding : Class ID #m (high byte) 
Binding : Instance ID #m (low byte) 
Binding : Instance ID #m (high byte) 
Status 
Default = 0 
Owner Vendor ID (low byte) Default = 
Owner Vendor ID (high byte) Default = 0 
Owner Serial Number (low byte) Default = 0 
Owner Serial Number Default = 0 
Owner Serial Number Default = 0 
Owner Serial Number (high byte) Default = 0 


Value Data Type Default = 0 
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5-22.4. 


5-22.5. 


Release 1.0 


Important: Insert default values for all unsupported attributes. 


Important: If the instance attribute Number of Attributes” is not supported, the default value 
of zero is to be inserted in its place and no members of the ’Attribute List” attribute will 
follow. 


Important: If the instance attribute Number of Bound Instances” is not supported, the default 
value of zero is to be inserted into the response byte array and no Binding data will follow. 


Object-specific Services 


The Analog Group Object provides no Object-specific services. 


Behavior 
The primary purpose of the Analog Group Object is to bind analog groups and/or points. 


An attribute of the AG modifies the behavior or reports additional status information of all 
objects bound to the group. 


The State Transition Diagram below provides a graphical description of the events and 
corresponding state transitions. A subset of the states and events may be supported in an 
application, but the behavior must be consistent. 


Except for highly configurable modules (which could have explicit Create and Delete events), 
the states shown in the STD are equivalent to the following: 


This state Is equivalent to 


Non-Existent a module without power 


a module that has an unrecoverable fault (e.g. processor 
watchdog timeout) 


a major reconfiguration of the module (e.g. NVS Update) 


Binding when the analog input and/or output groups and/or points 
are added or bound to the Analog Group (executed as 
part of Power Up cycle) 

Run the point at which Get and Set attribute services can be 


used to access the attributes of the Analog Group 
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Non-Existent 
< Power Down 


(any state) 
Power Up 


Binding 
Established 


Attribute Access Rules 


All attributes are gettable or settable according to their attribute access rules, but only in the 
Run state. 


The Status attribute is simply a logical OR of all possible failure or alarm conditions for all 
points bound to the group. 


Status 
——— Failures or Alarms 
for all points 


The Value Data Type attribute determines the data type to be used by all of the bound AIP’s 
Value attribute (and perhaps other attributes as well). If Value Data Type is not used, then 
Value defaults to INT. Value (and other attributes) may behave as REAL, USINT, or any other 
data type based upon the definition of Value Data Type, which ultimately provides the ability 
for the analog point to be defined in any length necessary. 


The Owner Vendor ID and Owner Serial Number are included in the object definition but 
their use is TBD. 
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5-23. POSITION SENSOR OBJECT 


Class Code: 23hex 


The Position Sensor Object models an absolute position sensor in a product. Behaviors in the 
object extend the basic position sensor capability to include zero offset, and position boundary 
checking (CAM switch). 


The Position Sensor Object interface is to real position sensor hardware such as an absolute 
digital encoder, an analog resolver or other absolute position-input device. 


5-23.1. Class Attributes 


Need in Access Name Data Description of 
Implementation | Rule Type Attribute 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Attr ID 


Semantics of 
Values 


5-23.2. Instance Attributes 
Attr ID Need in Access Name Data Description of Semantics of 
implementation | Rule Type Attribute Values 
1 Optional Number of Number of 
Attributes attributes supported 

in this product 

2 Optional Attribute List Array of | List of attributes 
USINT supported in this 
product. 


3 Required Get Value UDINT Current position. Physical position 
modified by the 
Resolution and 
Zero Offset 
Attributes. 


4 Optional Get CAM BOOL Virtual CAM switch | 0 = Off 
value 1=On 


Optional Get/Set | Value Bit Position sensor The useable 
Resolution resolution. May be | resolution of the 

greater or less than | position sensing 

the physical position | device. The default 

sensor resolution. is the physical 
resolution of the 
position sensing 
hardware. (valid 
range is | to 32) 
i.e. Setting this 
value to 7 limits 
Value to Oto 127 
(Before Zero Offset 
is applied). 
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Attr ID Need in Access Name Data Description of Semantics of 
implementation | Rule Type Attribute Values 


6 Optional Get/Set | Zero Offset UDINT Value attribute zero | This attribute 
offset, subject to offsets the Value 
Resolution attribute. | attribute after the 
Resolution 
Attribute has been 
applied. This 
effectively sets the 
zero point for the 
Value attribute. 
The default is 0. 
fi Optional Get/Set | CAM Low Limit UDINT Virtual CAM switch | The default is 0 
low limit. 
8 Optional Get/Set | CAM High Limit UDINT Virtual CAM switch | The default is 0 
high limit. 
9 


Optional Get/Set | SetZero BOOL Auto zero control. | A rising edge on 
this signal sets 
Zero Offset to the 
current position. 


5-23.3. Common Services 


The Position Sensor Object provides the following Common Services: 


Service Need in Service Name Description of Service 
Code Implementation 


OEhex | Conditional* | Required |Get_Attribute_Single | Returns the contents of the 
specified attribute. 


10hex Set_Attribute Single | Modifies an attribute value. 


* The Get_Attribute_Single service is required at the class level if any class attributes are 
implemented 


5-23.4. Object—specific Services 


The Position Sensor Object provides no Object—specific services. 


§-23.5. Behavior 


The State Transition Diagram (Figure 5-23.1) provides a graphical description of the events 
and corresponding state transitions. A subset of the states and events may be supported in an 
application, but the behavior must be consistent. 


The State Event Matrix (See Table 5-23.2) lists all pertinent events and the corresponding 
action to be taken while in each state. 


Important: Events can occur simultaneously, but the Fault events have priority if they occur 
simultaneously with other events. 
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5-23.1. State Transition Diagram for Position Sensor Object 


Non-Existent |<———— Power Down 
LED Off 


| Power Up 


Apply Attributes | @ available | Get/Set Attributes 


Connection Deleted —» | LED Flash Green 


(from any state) ; es 
Connection Transitions 


to Established 


Sample Trigger 
Fault 


Unrecoverable 


Fault 
LED Solid Red 


Get/Set Attributes Get/Set 


Unrecoverable Fault Attributes 


LED = I/O Status LED 


Important: Events can occur simultaneously, but the Fault events have priority if they occur 
simultaneously with other events. 
The following SEM contains these states: 


e Non-Existent: a module without power. 

e Available: waiting for a connection, power-up discrete input point defaults are set. 
e Run: Position Sensor sensing data from its input and transmitting the data. 

e Recoverable Fault: a recoverable fault has occurred. 

e Unrecoverable Fault: an unrecoverable fault has occurred. 


e The SEM also contains these events: 


This event Is 
Sample Trigger a change of state, cyclic timer trigger, application trigger 
Connection Deleted 1/O connection deleted. 
Apply_Attributes the Apply service of the I/O connection object the Position Sensor Object is 


connected to. Note: the application is responsible for validating the 
connection object’s attributes. 


Fault Cleared the application clearing a detected fault 


Connection Transitions | I/O connection transitions to Established. 
to Established 
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This event Is 


Connection Transitions | I/O connection transitions to Timed-Out 


to Timed Out state 


The figure below is a conceptual illustration of the state machine for a typical input object 
(producing application). The events listed above are represented by the dotted line labeled 
“state change.” 


I/O Message 


2 V/O data 
Explicit seas Input Object 
Messages Jee Producer Instance 


----l----- SER StateChange ..-*"" 
' Get_Attributes ! SPSS Biles etna ce ere ey 

: Set_Attributes 
1 Apply_Attributes ; 


Request Message 
Validation 


Table 5-23.2. State Event Matrix for the Position Sensor Object 


Event State 


Non-Existent Available Recoverable | Unrecoverable 
Fault Fault 
Sample Trigger Not Applicable Ignore event Sample data, Ignore event Ignore event 
Send data 


Apply Attributes Not Applicable Verify Return error Return error Ignore event 
attributes, return | (Object State | (Object State 
result Conflict) Conflict) 


Connection Deleted Not Applicable Ignore Event Transition to Transition to Ignore event 
Available Available 


Connection Not Applicable Transition to Ignore event Ignore event Ignore event 
Transitions to Run 

Established 

Connection ot Applicable Ignore event Transition to Ignore event Ignore event 
Transitions to Timed Recoverable 

Out state Fault 


Fault Cleared Not Applicable | Not Applicable | Not Applicable | Transition to Ignore event 
Run 
Get_Attribute Return Error Return value Return value Return value Ignore event 
(Object Does 
Not Exist) 
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Event 


Non-Existent Available Recoverable | Unrecoverable 
Fault Fault 
Set_Attribute Return Error Accept value Accept value | Accept value Ignore event 
(Object Does 
Not Exist) 


110 Status LED SondiGeeen | Fisted | SoldRed 


Attribute Access Rules 


Except in the Non-Existent and Unrecoverable Fault states, all attributes are gettable or settable 
according to their access rules. 


Value 

The Value Attribute represents the absolute position detected by the position sensor 
conditioned by the Resolution and Zero Offset attributes. Refer to the following descriptions of 
the Resolution and Zero offset attributes for details. 


Bit Resolution 


The Bit Resolution Attribute specifies the number of significant bits used for Value. The raw 
value is shifted left or right to supply the indicated number of significant bits. 


Resolution Value = 
> Physical Resolution (RawValue << (PhysicalResolution - Bit Resolution)) + ZeroOffset 
< Physical Resolution (RawValue >> (Bit Resolution - PhysicalResolution)) + ZeroOffset 
= Physical Resolution RawValue + ZeroOffset 


Example 


Raw Value Resolution | Adjusted Val. | Notes 


10 bit 0 to FFhex Bit Resolution < Physical Resolution, surplus bits are 
discarded 


(0 to 3FF rex) 

6 bit 0 to FFhex Bit Resolution > Physical Resolution, missing bits are 

(0 to 3Fhex) zero. Adjusted value will actually be 0 to FC,,, in 
multiples of 4 


10 bit 1 0 to 3FFhex Bit Resolution = Physical Resolution, no conversion. 
(0 to 3FF nex) 


Zero Offset 


The Zero Offset Attribute adjusts the zero point of Value. Zero Offset is added to Value to 
adjust the zero point. The Zero Offset Attribute is applied after the Resolution Attribute. 


If the result of the addition exceeds the maximum specified by the Resolution attribute the 
overflow bits are discarded. 


Example 


Adjusted Val. 


250 
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Adjusted Val. Zero Offset Value 


250 15! 
250 270 
250 249 * 


1 Value overflowed 
2 Value underflowed 


Auto Zero 


This attribute controls the auto-zero feature of the resolver. A rising edge (transition from 0 to 
1) on this attribute adjusts the Zero Offset attribute to a value that results in the Value attribute 
being zero. 


If the Zero Offset attribute is implemented as non-volatile, the AutoZero command must store 
the new Zero Offset value. 


CAM, CAM Low Limit, CAM High Limit 


The CAM attribute is a virtual CAM switch. The state of the CAM attribute is determined by 
the CAM Low Limit, CAM High Limit and Value attributes. The Value Attribute is used after 
the Resolution and Zero Offset Attributes have been applied. 


CAM Low Limit CAM is On (true, 1) if... CAM is Off (false, 0) if... 


> CAM High Limit | Value > CAM Low or Value < | Value <CAM Low and Value > CAM High 
CAM High 


< CAM High Limit | Value >CAM Low and Value | Value < CAM Low or Value > CAM High 
< CAM High 
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5-24. POSITION CONTROLLER SUPERVISOR OBJECT 


Class Code: 24hex 


The position controller supervisor handles errors for the position controller as well as Home 
and Registration inputs. 


5-24.1. Revision History 


Since the initial release of this object class definition, changes have been made that require a 
revision update of this object class. The table below represents the revision history: 


Revision Description 
01 Initial release 
02 1. Class Attributes 32 and 33 added 


5-24.2. Class Attributes 


Number Need in Access Name Data Type Description of Semantics of 
Implementation | Rule Attribute Values 


1 Get Revision UINT Revision of this The current value 
Required object. assigned to this 
attribute is two 
(02). 


2 thru 7 | These class attributes are either optional or conditional and are described in Chapter 4 of this 
specification. 


| 
| 


5-24.2.1 Consumed Axis Selection Number 


Get Consumed | USINT Specifies the axis | Value in the 
Axis number to which | range of 1-7 
Selection the data contained 
Number in the I/O 

Command 
Message is 
routed. 

Get Produced Specifies the axis | Value in the 
Axis number to which | range of 1-7 
Selection the data contained 
Number in the I/O 

Response 


Message is 
routed. 


When an I/O Message is consumed by the Position Controller Supervisor object, its internal 
destination may vary. The destination of the I/O Message shall be specified within the 
Command Axis Number. See Section 6-12.5: I/O Connection Messages of the Position 
Controller Device Profile for details. 


For static systems, this attribute is normally specified in the Consumed Connection Path of the 
respective I/O Connection instance. 
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5-24.2.2 Produced Axis Selection Number 
When an I/O Message is produced by the Position Controller Supervisor object, its internal 
source may vary. The source of the I/O Message shall be specified within the Response Axis 
Number. See Section 6-12.5: I/O Connection Messages of the Position Controller Device 
Profile for details. 


For static systems, this attribute is normally specified in the Produced Connection Path of the 
respective I/O Connection instance. 


5-24.3. Position Controller Supervisor Object Instance Attributes: 
5-24.3.1 Supervisor Attributes: 


ID Implementation | Rule Type 
1 Optional Get Number of | USINT | The total number of Return value is in the 
Attributes attributes supported by range of 0 to 255. 
this object in this device 
2 Optional Get Attribute Array |Returns an array witha | Array size defined by 
List of list of the attributes attribute 1. 
USINT | supported by this object 
in this device. 


3 Required Get Axis USINT | Returns the axis number _ | This value will be in the 
Number which is the same as the | range of 1 to 7. 

instance for this object. | The axis number is the 
same as the instance 
number for all of the 
axis objects: position 
controller supervisor, 
position controller, 
drive, motor data, and 
block sequencer. 


4 [Reserved | | 


5 Get General BOOL |General Fault flag. This | 1 = fault condition 
Fault bit is logical OR of all exists. 
fault condition attribute 
flags in the device. This 
bit is reset when the fault 
condition is removed. 
6 Set USINT | Sets the command Valid Message Type 


message type that is codes are | to 1F hex. 


being sent by the 1 = Type 01 hex 
controlling device. 


2= Type 02 hex, etc. 


7 Required Set Response USINT | Sets the response Valid Message Type 
Message message that is returned | codes are | to 1F hex.. 
Type to the controlling device |) — Type 01 hex 


2= Type 02 hex_etc. 


Fault Input |BOOL | Fault input fault 1 = fault input is active. 


oo 


Optional 


5-130 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 5: Object Library 


Attr Need in Access Name Data | Description of Attribute | Semantics of Values 
ID Implementation | Rule Type 


9 Optional Set USINT | Action taken when fault |0= Command Output 
i input becomes active Generator Off, 
code. 1 = Hard Stop , 
2 = smooth stop, 
3 =no action. Action 
codes 128 through 255 
are for vendor specific 
action. 


5-24.3.2 Home and Index Attributes: 


Attr Need in Access Name Data | Description of Attribute | Semantics of Values 
ID Implementation | Rule Type 


10 | Optional Set Home USINT |Home input action code. |0 = Command Output 
Action Action taken when armed | Generator off, 
home input is triggered. | 1 = Hard stop, 

2 = Smooth stop, 
3 = No action, 
4 = Gate index. Action 
codes 128 through 255 
are for vendor specific 
action. 


11 | Optional Set BOOL |Home trigger Active 0 = active low, 1 = 
Active level Level flag is used to active high. 
program the Home inputs 


active level. 


12 | Optional Get/Set |Home Arm |BOOL |Home trigger arm flag is | 1 arms the home input, 
used to arm the Home reading a 0 indicates the 
input. trigger has occurred. 


13 | Optional Set Index Action | USINT | Index input action code. |0 = Command Output 
Generator off, 
1 = Hard stop and, 
2 = Smooth stop, 
3 = No action. Action 
codes 128 through 255 
are for vendor specific 
action. 


14 | Optional Get/Set | Index BOOL | Used to program the 0 = active low, 1 = 
Active Level Index inputs active level. | active high. 
15 | Optional Get/Set |Index Arm |BOOL | Index trigger arm flag is | 1 arms the index input, 
used to arm the Index reading 0 indicates the 
i : trigger has occurred. 
16 | Optional Get Home Input |BOOL | Actual level of the Home |0 = Home input is low 
Level input. 1 = Home input is high. 


17 | Optional Get Home DINT _ | Home trigger position This value can be in the 
Position reflects the position at range of 0x80000001 to 
Pm | the time the home input | Ox7FFFFFFF. 
is triggered. 
18 | Optional Get Index trigger position This value can be in the 


reflects the position at range of 0x80000001 to 
the time the home input | Ox7FFFFFFF. 
is triggered. 
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5-24.3.3 Registration Attributes 


Attr Need in Access Name Data | Description of Attribute | Semantics of Values 
ID Implementation | Rule Type 


19 | Optional Registration | USINT | Registration input action |0 = Command Output 
Action defines what happens Generator off 

when the registration 1= Hard Stop 

input is triggered. 2 = Smooth stop 
3 = No action. 
4 = Go to Reg position 
offset 
5 = Go to Reg position 
absolute. Action codes 
128 through 255 are for 
vendor specific action. 


Set 
20 ‘| Optional Set Registration |BOOL | Registration trigger 0 = active low, 1 = 
Active level Active Level flag is used | active high. 

to program the 
Registration inputs active 
level. 

et 

et 

et 


21 ‘| Optional Get/Set | Registration |BOOL | Registration trigger arm | Set to 1 to arm the 
Arm flag is used to arm the registration input, 
Registration input. reading a 0 indicates the 
registration trigger has 
occurred. 


22 | Optional Registration }|BOOL | Actual level of the 0 = registration is low 
Input Level registration input. 1 = registration is high. 


23 ‘| Optional Registration |DINT | Defines a position value | This value can be in the 
Offset that is used as an offset | range of 0x80000001 to 
or absolute position Ox7FFFFFFF. 
dependent on the 
registration action code. 
24 | Optional G Registration |DINT | Registration trigger This value can be in the 
Position position reflects the range of 0x80000001 to 
position at the time the Ox7FFFFFFF. 
Registration input is 
triggered. 


5-24.3.4 Axis Following Attributes: 


G 
S 


Attr Need in Access Name Data | Description of Attribute | Semantics of Values 
ID Implementation | Rule Type 
27 | Optional Used to calculate the 
position with this value. 


25 | Optional Set Follow BOOL | Follow Enable enables 0 = following disabled, 
Enable following of the Follow | 1 = following enabled. 
Axis. 
26 | Optional Set Follow Axis | USINT | Specifies the Axis to 0 = no following, 
follow. 1 to 255 specifies the 
axis. 
Set 
Command Position by 
dividing the Follow Axis 
28 | Optional Set Used to calculate the 
Command Position by 
multiplying the Follow 
Axis position with this 
value. 
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5-24.4. Position Controller Supervisor Supported Services: 


Need in Name Service Description of Service 
fai Code 


Required | Get_Attribute Single Returns the contents of the specified attribute 
Set_Attribute Single Modifies the attribute value. 


5-24.5. Position Controller Supervisor State Diagrams 


5-24.5.1. Home Input State Diagrams 


The following state diagram describes the behavior of the Home input. The Home input active 
level can be programmed. Home will trigger when it is armed and the input goes to the active 

level. When home is triggered the home action is performed and the home input returns to the 
disabled state. 


Home Input 


Home Input Level 


Home Active Level 
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5-24.5.2 Index Input State Diagram 


The following diagram describes the behavior of the Index input. The Index input active level 
can be programmed. Index will trigger when it is armed and the input goes to the active level. 

In addition the index input can be gated using the Home input when the Home Action attribute 
is set to Gate index. When index is triggered the index action is performed and the Index input 
returns to the disabled state. 


Home Action 
(Gate index) 


Index Input Level 


Index Active Level 
Index Input 


Index Position 


Index Action 
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5-24.5.3. Registration Input State Diagram 


The following state diagram describes the behavior of the Registration input. The Registration 
input active level can be programmed. The Registration input will trigger when it is armed and 
the input goes to the active level. When the Registration input is triggered the Registration 
action is performed and the Registration input returns to the disabled state. 


Registration Arm 


Registration Input Registration Input 
Level 


Registration Position 
Registration Action 


Registration Active Level 
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5-25. 


5-25.1 


5-25.2. 


5-25.3. 
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POSITION CONTROLLER OBJECT 


Class Code: 25hex 


The position controller object performs the control output velocity profiling and handles input 
and output to and from the motor drive unit, limit switches registration etc. 


Revision History 


Since the initial release of this object class definition, changes have been made that require a 
revision update of this object class. The table below represents the revision history: 


Revision Description 
01 Initial release 
02 1. Instance Attribute 58 added 


Class Attributes 
Need in Access Name Data Type Description of 
Implementation | Rule Attribute 
Required Get Revision UINT Revision of this The current value 
object. assigned to this attribute 
is two (02). 


2 thru 7 | These class attributes are either optional or conditional and are described in Chapter 4 of this 
specification. 


Semantics of Values 


Position Controller Object Instance Attributes: 
Need in Access Name Data Description of 
Implementation | Rule Type Attribute 
Required Get Number of USINT Returns the total Return value is in the 
Attributes number of attributes | range of 0 to 255. 
supported by this 
object in this device. 
Required Get Attribute List | Array of | Returns an array with | Array size defined by 
USINT a list of the attributes | attribute 1. 
supported by this 
object in this device. 
Optional Mode USINT Operating mode. 0= Position 
mode(default), 
1 = Velocity mode, 
2 = Torque mode. 


Optional Set Position Units | DINT Position Units ratio | Set this value to a 
value is the number | positive number only. 
of actual position Default = 1. 
feedback counts 
equal to one 


Attr ID Semantics of Values 


position unit. 
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Attr ID Real in Access Name 
ee Rule 

5 Profile Units 

6 Set 

| ; 

| ; 

| : 

10 Optional Set Incremental 
Position Flag 

11 Required Set Load Data/ 
Profile 
Handshake 

| 

| . 

14 Optional Get Actual 
Velocity 

il) Commanded 


Position 


mae 
ret 
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Data 
Type 
DINT 


eerie of Semantics of Values 


eerie 


Profile Units ratio 
value is the number 
of actual position 
feedback counts per 
second or second” 
equal to one 
velocity, 
acceleration or 
deceleration unit.. 


This value is set to a 
positive number only. 
Default = 1. 


This value can be in the 
range of 0x80000001 to 
Ox7FFFFFFF. 


This value is set toa 
positive number only. 


Profile move 
position defined in 
position Units 


Profile velocity 
defined in profile 
units per second. 


DINT This value is set to a 


positive number only. 


Profile Acceleration 
rate defined in 
profile units per 
second’. 


DINT This value is set toa 


positive number only. 


Profile Deceleration 
rate defined in 
profile units per 
second’. 


BOOL Incremental Position 


Flag 


If set to 0 the target 
position (attribute 6) 
will be interpreted as 
absolute. If set to 1 the 
target position will be 
interpreted as 
incremental 


BOOL Used to Load 
Command Data, 
Start a Profile 
Move, and indicate 
that a Profile Move 


is in progress. 


See “Semantics” at end 
of this table. 


BOOL Reads Set when the 
Target position equals 
the actual position 
within deadband limits. 
Will clear if target 


position is changed. 


On target position 
flag indicates that 
the motor is within 
the deadband 
(Attribute 38) 
distance to the target 
position. 

Actual Absolute 
position value 
equals the real 
position in position 
units. Set to re- 
define Actual 
Position 


Actual Velocity in 
profile units/sec. 
This value equals 
the instantaneous 


DINT When set this value can 
be in the range of 
0x80000001 to 


Ox7FFFFFFF. 


DINT Value read will be 


positive. 
DINT When read this value 
will be in the range of 
0x80000001 to 


Ox7FFFFFFF. 


calculated position. 
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Attr ID Need in Access Name Data 
Implementation | Rule Type 


Commanded 
Velocity 


DINT 


calculated velocity 
in profile units per 
second. 

Enable Output. 


ie 
a 


17 


7 “ 


18 Profile Type code 
defines the type of 


move profile. 


Set Profile Type | USINT 


19 | Profile Gain |DINT 


20 Set Smooth Stop |BOOL 


21 aa Hard Stop BOOL 
22 Pe Jog Velocity |DINT 


This attribute 
provides a gain 
value for non- 
trapezoidal profiles 
such as S-Curve 
profiling. The 
implementation and 
function of this gain 
is vendor specific. 


Smooth stop motor. 


Hard stop motor. 


Defines the jogging 
velocity in profile 
units per second. 


23 Optional Set Direction BOOL Instantaneous 
direction 
24 Set Reference BOOL Defines direction. 
Direction 
25 Set Torque DINT Output torque. 
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Description of Semantics of Values 
Attribute 


This value equals 
the Instantaneous 


Value read will be 
positive. 


Set to enable drive and 
feedback, clear to 


disable. 
0 = Trapazoidal, 
1 = S-Curve, 


2 = Parabolic. 128 to 
255 = vendor specific 
profile types. 


Range is defined by the 
vendor. 


Set to force immediate 
deceleration to zero 
velocity at programmed 
decel rate. 

Set to force immediate 
deceleration to zero 
velocity at max decel 
rate. 

This value is set to a 
positive number only. 


0 = negative or reverse 
direction and | = 
positive or forward. 
This value can be set in 
Velocity mode to 
change direction. 

0 = forward direction is 
clockwise, 

1 = reverse direction is 
counter clockwise as 
viewed from the load 
end of the motor shaft. 


Set this value to change 
the torque (Torque 
mode only) or read the 
current torque. 0 = no 
torque output. Range 


defined by the vendor. 
26 Optional Set Positive DINT This value sets the | This value is set to a 
Torque Limit maximum allowable | positive number only. 
torque output in the | Range defined by the 
positive direction. | vendor. 
Release 1.0 
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DINT 


INT 


INT 


USINT 


7 
| a 
30 
31 
32 
33 
. 7 
35 
36 Optional Set Accel Feed 
Forward 
38 Optional Set Position 
Deadband 
39 Feedback 


| 
| 


Enable 


Feedback 
Resolution 


Motor 
Resolution 


BOOL 


DINT 


DINT 
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Attr ID Need in Access Name Data Description of Semantics of Values 
Implementation | Rule Type Attribute 


Negative 
Torque Limit 


This value sets the 
maximum allowable 
torque output in the 


negative direction. 


a 


Position Wrap 
Around indicator 
Flag 


Integration limit 
Mode. 


This value is set to a 
negative number only. 
Range defined by the 
vendor. 


If set to 1 the motor has 
gone past its maximum 
position. This can only 
happen in Velocity 
mode and is not 
necessarily a fault 
condition. This bit is 
reset when read. 


Range i 010 32707 
Range i 010 32767. 
Range is 010 32767. 
Range 6 010 32767. 


0 = use Ki term at all 
times, 

1 = use Ki term only 
when stopped and 
holding position. 


Optional Set Velocity Feed | INT Velocity feed Range is 0 to 32767. 
Forward. forward gain value. 


Acceleration feed Range is 0 to 32767. 
forward gain value. 


Update sample rate 
in Seconds. 


Set this value to 
prevent axis hunting 
within the desired 
window. 

This flag will set or 
clear automatically 
with the Enable 
attribute (17). 
Feedback can be 
turned off, using this 
attribute, leaving the 
enable on, for offset 
adjustments on the 
drive unit 

Feedback resolution 
in counts. Number 
of actual position 
feedback counts in 
one revolution of 
the position 
feedback device. 


Motor resolution in 


motor steps. 
Number of motor 
steps in one 
revolution of the 
motor. 
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Value returned is 
positive. 


Range is 0 to 255. 


0 = command output 
generator off, 
1 = command output 
generator on. 


This value is set toa 
positive number only. 


This value is set toa 
positive number only. 
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Attr ID Need in Access Name Data Description of Semantics of Values 
Jmplements won Rule Type Attribute 


Position 
Tracking 
Gain 


| 
| 


| 


| 
| 
| 
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Max 
Correction 
velocity 


Max Static 
Following 
Error 


Max Dynamic 
Following 
Error 


Following 
Error Action 


Following 
Error Fault 


DINT 


UINT 


DINT 


DINT 


USINT 
BOOL 


DINT 
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Position Tracking 
Gain (Stepper) Gain 
value for position 
maintenance to 
control steppers 


with position 
feedback. 

Position 
maintenance value 
to prevent stepper 


motor stalls. Value 
in counts per 
second. 

Maximum allowable 
following error 
when the motor is 
stopped and holding 
position. If the 
difference between 
actual and 
commanded position 
exceeds this value, 
following error flag 
is set. 


Maximum allowable 
following error 
when the motor is in 


motion. If difference 
between actual and 
commanded position 
exceeds this value, 
following error flag 
is set. 

Following error 
action code. 


Following error 
occurrence flag. Set 
when a following 
error occurs. This 
bit is reset when 
another move is 
attempted. 


Actual Following 
Error. 


Range defined by the 
vendor. 


This value is set to a 
positive number only. 


Set to value to a 
positive number only. 


Set to value to a 
positive number only. 


0 = Command Output 
Generator Off, 

1 = Hard Stop, 

2 = Smooth stop, 3 = no 
action. Action codes 
128 through 255 are for 
vendor specific action. 
Set when a following 
error occurs. This bit 
can be cleared directly 
or by re-programming 
the Following Error 
Action attribute. 


This value is the actual 
amount of Following 
Error in position 
feedback counts. 


Release 1.0 
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Attr ID Need in Access Name Data Description of Semantics of Values 
Implementation | Rule Type Attribute 
49 Optional Set Hard Limit USINT Hard limit action 0 = Command Output 
Action code. Generator Off 
1 = Hard Stop 
2 = smooth stop. Action 
codes 128 through 255 
are for vendor specific 
action. 

50 Optional Get Forward Limit | BOOL Motion is not Set when the forward 
allowed in the limit stop is active. 
positive direction 
when active. 

51 Optional Get Reverse Limit |} BOOL Motion is not Set when a reverse limit 
allowed in the stop is active. 
negative direction 
when active. 

52 Optional Set Soft Limit BOOL Enables soft limits | When set, motion that 

Enable exceeds the defined 
limits will result in a 
motor stop. 

53 Optional Set Soft Limit USINT Soft limit action 0 = Command Output 

Action code. Generator Off, 
1 = Hard Stop, 
2 = smooth stop. Action 
codes 128 through 255 
are for vendor specific 
action. 

54 Optional Set Positive Soft | DINT Soft limit positive | This value can be in the 

Limit Position boundary defined in | range of 0x80000001 to 
position units.. Ox7FFFFFFF. 

ES) Optional Set Negative Soft | DINT Soft limit negative | This value can be in the 

Limit Position boundary defined in | range of 0x80000001 to 
position units.. Ox7FFFFFFF. 

56 Optional Get Positive Limit | BOOL Hard Forward limit | Set when a positive 

Triggered occurrence flag. limit stop occurs. 

57 Optional Get BOOL Hard Reverse limit | Set when a negative 
occurrence flag. limit stop occurs. 

58 Required Get Load Data BOOL Indicates that valid | See “Semantics” at the 

Complete data for a valid I/O | end of this table. 
command message 
type has been 
loaded into the 
position controller 
device. 


Semantics: 


Profile in Progress 

This attribute performs three functions: 

e loading data in the I/O command message; 

e starting a Profile Move in the both the i/o command message and explicit messaging; and 


e indicating if a Profile Move is in process. See the chart below for a complete explanation of 
the device's behavior with respect to this bit. 
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5-25.4. 


5-25.5. 


5-25.5.1. 


5-142 


Connection | Message | Bit Name | Behavior 
Type or 
Service 
0) Command | Load Data/ | When this bit transitions from zero to one, the position 
Start controller device will attempt to load the data contained in 
Profile the command message data bytes. If the command message 
type contained in the command message is the command 
message type that starts a Profile Move, the Profile Move 
will start. See the table in Section 3-12.4.3 for an 
explanation of which command message type starts a Profile 
Move for each mode. 
Response | Profile in This bit will indicate that a Profile Move is in progress. This 
Progress bit will read 1 when a Profile Move is started and will remain 
1 until the Profile Move is complete or terminated, at which 
point it will be zero. 
Explicit Set Start A "Set Attribute Single" service which sets this attribute to 1 
Attribute Profile will start a Profile Move. A "Set Attribute Single" service 
Single which sets this attribute to 0 will have no effect. 
Get Profile in This bit will indicate that a Profile Move is in progress. This 
Attribute Progress bit will be one after receipt of a set attribute service which 
Sinble sets this attribute to 1 and will remain 1 until the profile 
move is complete or terminated, at which point it will be 
zero. 


Load Data Complete 


This bit is used for data handshaking in the I/O message. It reflects that the position controller 
device has successfully loaded the data contained in the I/O command messagedata bytes. This 
attribute will be reset when the Load Command Data/Start Profile bit is reset. Refer to Section 
3-12.4.4 for an explanation of the handshaking procedure. This bit is not affected by explicit 
messaging. 


Position Controller Supported Services: 


Need in Name Service Description of Service 
= Code 


a | Get_Attribute_Single Returns the contents of the specified attribute 
Set_Attribute Single Modifies the attribute value. 


Position Controller State Diagrams 


Profile Move Generation State Diagrams 


The state diagram below describes Position Controller profile generation. The Profile 
generator uses Acceleration, Target, Velocity and Deceleration to perform a profile move to the 
Target Position. In profile velocity mode the Target Position is infinite with polarity defined 
by the direction attribute until such time the device is commanded to decelerate and stop. 


After the profile position is generated, it passes through a limit filter. If the generated Profile 
position is outside the defined software limits, or if a hardware limit is active, the profile is 
modified and the output Command position is limited. The limit function and attributes are 
optional. 
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Release 1.0 


The Command Position is then sent to the output generator, which produces a control signal. 
The output generator can be servo, stepper or some other method for controlling position. 
Commanded Acceleration and Velocity are also sent to the output generator for feed forward 
purposes. Feedback is optional unless required by the output method being used. 


Target Position 


(Velocity Mode) 


Target Velocity 
Profile 
Generator 


Profile Position 


Position Limit 


Command Accelleration 


Hardware Limits (CW, CCW) 
Software Limits (Fwd, Rev) 


Command Output 
Generator 


Drive & Motor 
Feedback (optional) 
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5-25.5.2. Servo Output Generation State Diagram 


The diagram below is an example of a Servo Command output generator. Commanded 
Position, Velocity and Acceleration input comes from the Profile Generation diagram. 


Command Command Command 
Acceleration Velocity Position 
C) = Actual 

Position 


Static Following Err. : 


Dynamic Following Err. 


5 ed 


Velocity 
Feed Forward 


Acceleration 
Feed Forward 


Positive Torque Limit 


Negative Torque Limit ) 


Torque Command 
Output 


Drive & Motor 
with Feedback 
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5-25.5.-3. Torque Mode Output State Diagram 


The following diagram describes the direct torque mode function. 
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5-26. BLOCK SEQUENCER OBJECT 


Class Code: 26hex 


This object handles the execution of Command Blocks or Command Block chains. 


5-26.1. Class Attributes 


Need in Access Name Data Type | Description of 
Implementation | Rule Attribute 


1 thru7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Semantics of 
Values 


Number 


5-26.2. Block Sequencer Object Instance Attributes: 


These attributes can be used for control, configuration or status. 
Need in Access Name Data Description of 
Implementation | Rule Type Attribute 
Required Set/Get | Block USINT Instance number _ | This value Defines the 
of starting Command Block 
Command Block. | instance to execute. 
Set from 1 to 255. 


Required Get/Set | Block Execute |BOOL Block execution | Setting this value 
flag. executes the block 

defined by the Block 
Attribute (1). When 
this value reads back 
cleared, the block or 
chain of blocks is 
done. 


Required Get Current Block | USINT Current block in | This value contains the 
execution. Command Block 
instance number of the 
currently executing 
block (1 - 255). 
Block Fault BOOL Block fault flag. | Set when a block error 
occurs, such as the 
Wait Equals command 
time-out or execution 
of an invalid 
Command Block. 
when a Block Fault 
occurs block execution 
will stop. This bit is 
reset when the Block 
Fault Code attribute 
(5) is read. 
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Attr ID Need in Access Name Data Description of | Semantics of Values 
Implementation | Rule Type Attribute 


5 Optional Get Block Fault Block fault Code. | Defines the specific 
Code block fault. 

0=no fault, 
1 = invalid or empty 
block data, 
2 = command time-out 
(Wait Equals) , 
3 = execution fault. 


6 Optional Set Counter DINT Sequencing Must be positive. 
Counter. Counter that can be 
used for sequencing 
loops. 


5-26.3. Block Sequencer Supported Services: 


Need in Name Service Description of Service 
ees Code 


[Reguied | Get_Attribute_Single Returns the contents of the specified attribute 
Set_Attribute Single Modifies the attribute value. 


5-26.4. Block Sequencer State Diagrams 


The diagram below describes the Block Sequencer. When the Sequencer is commanded to 
execute a block, the Block Execution state is entered. Block execution continues on 
consecutive blocks until the end of the linked chain is reached or an error occurs. 


Block ) 


Block Fault CB lock Fault ) Current Block) 
Code 
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5-27. COMMAND BLOCK OBJECT 


Class Code: 27hex 


Each instance of the Command Block object defines a specific command. These blocks can be 
linked to other blocks to form a command block chain. 


5-27.1. Class Attributes 


Need in Access Name Data Type Description of 
Implementation | Rule Attribute 


1 thru7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Number Semantics of Values 


5-27.2. Command Block Object Instance Attributes: 


These attributes are down-loaded at configuration time and executed at run time through the 
Block Sequencer object. Attributes 3, 4, and 5 definitions are dependent on the block 
command attribute (01). Each instance of the Block command class defines a different block 
command that can be linked to any other block command instance to form an execution 
sequence. 


Implementation | Rule Attribute 
1 Required Set Block USINT Block Command | Defines the format of the 
Command block data. Command 
data formats are defined 
below. 
2 Required Set Block Link # | USINT Block link This value provides a link 
instance number. | to the next block instance 
to execute. When this 
block is done, the link 
block will be executed. 


3 Depends on Set Depends on Depends on Refer to the command 
Command Command Command definitions for the 
description of attribute 3. 
4 Depends on Set Depends on | Depends on Refer to the command 
Command Command Command definitions for the 
description of attribute 4. 
> Depends on Set Depends on | Depends on Refer to the command 
Command Command Command definitions for the 
description of attribute 5. 
6 Depends on Set Depends on | Depends on Refer to the command 
Command Command Command definitions for the 
description of attribute 6. 
7 Depends on Set Depends on | Depends on Refer to the command 
Command Command Command definitions for the 
description of attribute 6. 


5-27.3. Command Specific Attribute Services: 


This section defines the Command block data. Command blocks can be linked together to 
form a command block chain. Looping and branching commands are supported. 
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5-27.3.1. Modify Attribute Command - 01 


This command is used to change an attributes value. Attribute 1 must be set to 01. 


Attr ID Need in Access Name Data Type | Description of Semantics of Values 
Implementation | Rule Attribute 
3 Required for Target Class | USINT Target class This value Defines the 
Command 01 number to class which will be 
perform block —_| sequenced. 
sequencing on. 


4 Required for Target Target instance | This value Defines the 
Command 01 Instance number of the instance of the class which 
class to perform | will be sequenced. 
block 
sequencing on. 


> Required for Attribute # USINT Position Position Controller class 
Command 01 Controller attribute number. Must be 
Attribute a settable attribute. 


6 Required for Attribute Data | Dependent | Attribute Data. |The new Attribute data. 
Command 01 on attribute 
# 


5-27.3.2. Wait Equals Command - 02 


This command is used to stop execution of a linked chain of command until an attribute 
becomes valid. Attribute | must be set to 02. 


Attr ID Need in Access Name Data Type | Description of Semantics of Values 
Implementation | Rule Attribute 
3 Required for Set Target Class | USINT Target class This value Defines the 
Command 02 number to class which will be 
perform block —_| sequenced. 
sequencing on. 
Set 


4 Required for Target Target instance | This value Defines the 
Command 02 Instance number of the instance of the class which 
class to perform | will be sequenced. 
block 


sequencing on. 


Attribute # USINT Position Position Controller class 
Controller attribute number. Must be 
Attribute a settable attribute. 


6 Required for Set Compare DINT Compare Time- | Set from 0 to 7FFFFFFF 
Command 02 Time-Out out value in hex. If compare does not 
value milliseconds. happen within time-out a 
fault is generated and 
motion stops. 0 = no time- 
out. 


5 Required for 
Command 02 


7 Required for Compare Data | Dependent | Compare data If the attribute listed above 
Command 02 on attribute | for end of is Becomes equal to the 
# command. compare data the block is 
done and the next link 
block is executed. 
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5-27.3.3. 


5-27.3.4. 
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Conditional Link Greater Than Command - 03 


This command is used for conditional linking or branching in a linked chain of commands. 
Attribute 1 must be set to 03. 


Attribut Need in Access Name Data Type | Description of Semantics of Values 
eID Implementation | Rule Attribute 
3 Required for Target Class | USINT Target class This value Defines the 
Command 03 number to class which will be 
perform block —_| sequenced. 
sequencing on. 
Target USINT Target instance | This value Defines the 
Instance number of the instance of the class which 
class to perform | will be sequenced. 
block 
sequencing on. 


5 Required for Set Attribute # USINT Position Position Controller class 
Command 03 Controller attribute number. Must be 
Attribute a settable attribute. 


4 Required for 
Command 03 


6 Required for Compare Link | USINT Conditional Alternate Link block if 
# Link Number. attribute is greater than 
compare data. 


Command 03 
Compare Data | Dependent | Compare data If the attribute listed above 

on attribute | for conditional | is greater than the compare 

# link. data the normal link 
attribute (02) is ignored 
and the next block 
executed is the compare 
link block. 


Conditional Link Less Than command - 04 


7 Required for 
Command 03 


This command is used for conditional linking or branching in a linked chain of commands. 
Attribute 1 must be set to 04. 


Attr ID Need in Access Name Data Type | Description of Semantics of Values 
Implementation | Rule Attribute 


3 Required for S Target Class | USINT Target class This value Defines the 
Command 04 number to class which will be 
perform block —_| sequenced. 
sequencing on. 


4 Required for Set Target instance | This value Defines the 
Command 04 number of the instance of the class which 
class to perform | will be sequenced. 
block 
sequencing on. 
5 Required for Set Attribute # USINT Position Position Controller class 
Command 04 Controller attribute number. Must be 
Attribute a settable attribute. 
Set Compare Link | USINT Conditional Alternate Link block if 
# Link Number. attribute is less than 
compare data. 
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Attr ID Need in Access Name Data Type | Description of Semantics of Values 
Implementation | Rule Attribute 


7 Required for Set Compare Data | Dependent | Compare data If the attribute listed above 
Command 04 on attribute | for conditional | is less than the compare 
link. data the normal link 


attribute (02) is ignored 
and the next block 
executed is the compare 
link block. 


5-27.3.5. Decrement Counter Command - 05 


This command is used to decrement the Block Sequencers counter attribute used for looping. 
Attribute 1 must be set to 05. 


Attribut Need in Access Name Data Type | Description of Semantics of Values 
eID Implementation | Rule Attribute 


No additional attributes required for this command 


5-27.3.6. Delay Command - 06 


This command is used to perform a delay in a linked chain of commands. Attribute 1 must be 
set to 06. 


Attr ID Need in Access Name Data Type | Description of Semantics of Values 
Implementation | Rule Attribute 
3 Required for Set Delay DINT Delay in Set the delay in 
Command 06 Milliseconds milliseconds 1 hex to 
7FFFFFFF hex 


5-27.3.7.. Trajectory Command - 07 


This command is used to initiate a move. Attribute 1 must be set to 07. 


Attr ID Need in Access Name Data Type | Description of Semantics of Values 

Implementation | Rule Attribute 

3 Required for Set Target DINT Target Position. | Profile destination defined 
Command 07 Position in position Units 

4 Required for Set Target DINT Target Velocity. | Profile velocity defined in 
Command 07 Velocity profile units per second. 

> Required for Set Incremental |BOOL Absolute / 0 = absolute position, 1 = 
Command 07 Incremental flag. | incremental position 
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5-27.3.8. Trajectory Command and Wait - 08 


This command is used to initiate a move and wait for completion. Attribute 1 must be set to 
08. 


Implementation | Rule Attribute 

3 Required for Profile destination defined 
Command 08 Position in position Units 
Command 08 Velocity profile units per second. 

5 Required for Set Incremental |BOOL 0 = absolute position, 1 = 
Command 08 Incremental flag. | relative position 


5-27.3.9. Velocity Change Command - 09 


This command is used to initiate a move and wait for completion. Attribute 1 must be set to 


09. 
Attr ID Need in Access Name Data Type | Description of Semantics of Values 
Implementation | Rule Attribute 
3 Required for Profile velocity defined 


Command 09 in profile units per 
second. 


5-27.3.10. Goto Home Command - 10 


This command is used perform a move to the captured Home position. Attribute 1 must be set 
to 10. 


Implementation | Rule Attribute 
3 Required for Set Home Offset | DINT Home Position | The offset plus the 
Command 10 Offset captured Home position 
equals the absolute target 
position. 
4 Required for Set Velocity DINT Target Velocity. | Profile velocity defined 
Command 10 in profile units per 
second. 


5-27.3.11. Goto Index Command - 11 


This command is used perform a move to the captured Index position. Attribute 1 must be set 
to 11. 


Implementation | Rule Attribute 
3 Required for Set Index Offset | DINT Index Position _| The offset plus the 
Command 11 Offset captured Index position 
equals the absolute target 
position. 
4 Required for Set Velocity DINT Target Velocity. | Profile velocity defined 
Command 11 in profile units per 
second. 
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5-27.3.12. Goto Registration Position Command - 12 


This command is used perform a move to the captured Registration position. Attribute 1 must 


be set to 12. 
Attr ID Need in Access Name Data Type | Description of Semantics of Values 
Implementation a Attribute 


3 Required for Registration Registration The offset plus the 
Command 12 Offset Position Offset | captured Registration 

position equals the 

absolute target position. 


4 Required for Set Velocity DINT Target Velocity. | Profile velocity defined 
Command 12 in profile units per 
second. 


5-27.3.13. Command Block Supported Services 


Need in Name Service Description of Service 
Implementation Code 


Get_Attribute_Single Returns the contents of the specified attribute 
Set_Attribute_Single Modifies the attribute value. 
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5-28. MOTOR DATA OBJECT 


Class Code: 28hex 


This object serves as a database for motor parameters. 


5-28.1. Motor Data Class Attributes 


Need in Access Name Data Type | Description of 
Implementation | Rule Attribute 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Attribute 
ID 


Semantics of 
Values 


5-28.2. Motor Data Instance Attributes 
The Motor Data Instance Attribute set varies depending on the type of motor that the object is 
representing. Instance attribute 3 “MotorType” is required, and its value determines the motor 


specific attributes that are available for that motor type. For all motor types, Attributes 1-5 are 
the same. 


Attribute Need in Access Name Data Type Description of Attribute 
ID implementation | Rule 


1 Optional NumAtttr JUSINT Number of Attributes supported 
Pp 


2 Optional Attributes Array est List of attributes supported 
USINT 


3 Required Set/Get | MotorType USINT 0 - Non-standard motor 
1 - PM DC Motor 
2 - FC DC Motor 
3 - PM Synchronous Motor 
4 - FC Synchronous Motor 
5 - Switched Reluctance Motor 
6 - Wound Rotor Induction Motor 
7 - Squirrel Cage Induction Motor 
8 - Stepper Motor 
9 - Sinusoidal PM BL Motor 
10 - Trapezoidal PM BL Motor 


4 Optional Set/Get | CatNumber SHORT_ Manufacturer's Motor Catalog Number 
STRING (Nameplate number) 32 chars max 

5 Optional Set/Get |Manufacturer |SHORT_ Manufacturer's Name 32 chars max 
STRING 


5-28.2.1. Motor Type Specific Motor Data Instance Attributes 


Different motor types require different data to describe the motor. For example, AC Induction 
motors do not need field current data like a DC motor to describe the motor. For this reason, 
motor data attributes that are numbered greater than 5 are described separately for different 
classes of motors. The following table shows the classes of motors described in this 
specification. Other motor classes and types will be described in future revisions of this 
specification. 
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Motor Class Motor Types in Class Section Reference 


AC Motor 3-PM Synchronous 5-28.2.1.1 
6 - Wound Rotor Induction 


7 - Squirrel Cage Induction Motor 
DC Motor 1 - PM DC Motor §-28.2.1.2 


2 - FC DC Motor 


5-28.2.1.1. AC Motor Instance Attributes 


Attribute Need in Data Type Description of Attribute 
ID implementation | Rule 
6 Required Set/Get |RatedCurrent | UIN Rated Stator Current 
Pape | nits: [100mA] 

7 Required Set/Get |RatedVoltage | UIN Rated Base Voltage 

8 Optional Set/Get | RatedPower UDINT Rated Power at Rated Freq 
Optional Set/Get | RatedFreq U Rated Electrical Frequency 
Optional U Rated Winding Temperature 
11 Optional Set/Get | MaxSpeed U 


12 Optional UIN Number of poles in the motor. 


13 Optional Set/Get |TorqConstant | UDINT Motor torque constant 
Pare | nits: [0.001 x Nm/A] 

14 Optional Set/Get | Inertia UDINT Rotor Inertia 
roe | nits: [10-6 X kg.m2] 


15 Optional Set/Get | BaseSpeed UIN Nominal speed at rated frequency 
from nameplate 

19 Optional Set/Get |ServiceFactor | USINT Units: [%] 

Range: 0 .. 255 


4 4 
Cc 


ae 


‘o 
Se 


— 
Co 


Ee 


nits: [ degrees C] 


Z 


—_ —_ — 
Z Z 
4 4 4 
Cc 


Maximum allowed motor speed 


=, 


4 


ie 


e, 


al 


G 


nits: [RPM] 
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5-28.2.1.2. DC Motor Instance Attributes 


ID implementation | Rule 
8 Optional Set/Get | RatedPower 
Pee | aaa (sa 
10 Optional RatedTemp UINT 
: 
13 Optional Set/Get | TorqConstant 
: 
" 
: 
: 
18 


RatedFieldVolt | UINT 
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Description of Attribute 


Rated Armature Current 
nits: [100mA] 

Rated Armature Voltage 
Units: [V] 

Rated Power at MaxSpeed 
Units: [W] 


eG 


Rated Winding Temperature 
Units: [ degrees C] 

Maximum allowed motor speed 
Units: [RPM] 

Motor torque constant 

Units: [0.001 x Nm/A] 

Rotor Inertia 

nits: [10-6 X kg.m2] 
Nominal speed at rated voltage 
Units: [RPM] 

Rated Field Current 

nits: [mA] 

Minimum Field Current 

nits: [mA] 

Rated Field Voltage 

Units: [V] 


(= 


ae 


(cm 


The following engineering abbreviations are used in the above Motor Data Instance Attribute 


Description of Service 


Returns the contents of 
the specified attribute. 


Modifies an attribute 


descriptions. 
Abbreviation Description 
mA milli Amps 
V Volts 
RPM Revolutions Per Minute 
Kg.m2 kilograms times meters squared 
Nn/A Newton meters per Amp 
Degrees C degrees Centigrade 
Hz Hertz 
WwW Watts 
5-28.3. Motor Data Object Common Services 
Service | Need in Implementation Service Name 
Code 
OEhex Get_Attributes_Single 
10hex n/a Required Set_Attributes_Single 
value. 
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Service | Need in Implementation Service Name Description of Service 
Code 


15hex n/a Optional Restore Restores attribute values 
from a storage location 
accessible by the Save 
service. Service is only 
available if the Control 
Supervisor Object of the 
drive is in the Ready or 
Wait_Power states. 


16hex Optional Save Saves all attribute values 
to a location accessible by 
the Restore service. 


* The Get_Attribute_Single service is required at the class level if any class attributes are 
implemented 


See Appendix A for definitions of these common services. 
Motor Data Object-—specific Services 
The Motor Data object provides no object specific services. 


Motor Data Object Behavior 
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The Motor Data Object serves only as an internal database for motor parameters which are 


accessed by other objects in the drive. 
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5-29. CONTROL SUPERVISOR OBJECT 
Class Code: 29hex 
This object models all the management functions for devices within the “Hierarchy of Motor 
Control Devices”. The behavior of motor control devices is described by the State Transition 
Diagram and the State Event Matrix (see Section 5-29.5.). 
5-29.1. Control Supervisor Class Attributes 
Attribute Need in Access Name Data Type Description of Semantics of 
Se] | eS 
1 thru7 | These class attributes are optional and are described in Chapter 4 of this specification. 
5-29.2. Control Sup ervisor Instance Attributes 
we eue Description of Attribute 
LULL Rule 
z Number of Attributes supported 
2 Optional Get Attributes Array of List of attributes supported 
ae aa 
3 See Run/Stop Event Matrix 
4 See Run/Stop Event Matrix 
5 Optional Set/Get | NetCtrl BOOL Requests Run/Stop control to be 
local or from network. 
0 = Local Control 
1 = Network Control 
Note that the actual status of 
Run/Stop control is reflected in 
attribute 15, CtrlFromNet. 
6 Optional Get State USINT 0 = Vendor Specific 
1 = Startup 
2 = Not_Ready 
3 = Ready 
4 = Enabled 
5 = Stopping 
6 = Fault_Stop 
7 = Faulted 
¢ Required for Get Running 1 BOOL 1 = (Enabled and Run1) or 
Drives and (Stopping and Running!) or 
Servos only (Fault_Stop and Running1) 
0 = Other state 
8 Optional Get Running2 BOOL 1 = (Enabled and Run2) or 
(Stopping and Running2) or 
(Fault_Stop and Running?) 
0 = Other state 
9 Optional Ready BOOL 1 = Ready or Enabled or Stopping 
10 Required for Faulted BOOL 1 = Fault Occurred (latched) 
Drives and 0 =No Faults present 
Servos only 
11 Optional Warning BOOL 1 = Warning (not latched) 
0 = No Warnings present 
If warnings are not supported, this 
attribute should always be 0 
Release 1.0 
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Attribute Need in Access Name Data Type Description of Attribute 
ID implementation | Rule 
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13 


14 


15 


16 


17 
18 


Required for Set/Get | FaultRst BOOL 0->1 = Fault Reset 
Drives and 0 =No action 
Servos only 


Optional Get FaultCode UINT If in Faulted state, FaultCode 
indicates the fault that caused the 
transition to Faulted state. If 
multiple faults occurred 
simultaneously, the vendor 
chooses which to report, and the 
rest are lost. If not in Faulted 
state, FaultCode indicates the fault 
that caused the last transition to the 
Faulted state. 

Power up state of fault code is 
vendor specific. 

Fault codes for drives are different 
than fault codes for starters. 

See appropriate device profile for 
fault codes. 


Optional Get WarnCode UINT Code word indicating warning 
present. If multiple warnings are 
present, the lowest code value is 
displayed. 

Note that fault codes for drives and 
servos are different than fault 
codes for starters. 

See appropriate device profile for 
fault codes. 


Optional Get CtrlFromNet BOOL Status of Run/Stop control source. 
0=Control is local 
1=Control is from network 
Optional Set/Get | DNFaultMode | USINT Action on loss of CIP Network 
0 = Fault + Stop 
1 = Ignore (Warning Optional) 
2= Vendor specific 


Optional Get ForceStatus BOOL 0 = Not Forced 
Nonzero = Forced 
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5-29.3. Control Supervisor Common Services 


Service Need in Implementation Service Name Description of Service 
Code 


OEnhex Conditional Required Get_Attributes_Single Returns the contents of the 
specified attribute. 


10hex n/a Set_Attributes_Single Modifies an attribute value. 


O5hex n/a Required _| Reset Resets the drive to the start- 
up state. 


5-29.4. Control Supervisor Object Specific Services 


The Control Supervisor object provides no object specific services. 


5-29.5. Control Supervisor Behavior 


The State Transition Diagram provides a graphical description of the states and corresponding 
state transitions. The State Event Matrix lists all events and the corresponding action to be 
taken while in each state. A subset of states and events may be supported in an application but 
the behavior must be consistent. 


Control Supervisor State Transition Diagram 


Non-Existant 


Switch On 


Initialization Complete 


Switch Off 


Fault Detected Main Power Off 


Reset 


Faulted 


Fault_Stop 
Complete 


Fault Reset 


Fault Detected 


Fault_Stop 


Fault 
Detected 


Not_Ready 


= Main Power Off 


ae © _— 
Enabled 


Main Power On 
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Event State 
Faulted 
Switch Off N/A Transition to | Transition to | Transition | Transition | Transition | Transition to | Transition 
Non_Exist | Non Exist | to to to Non_Exist | to 

Non Exist | Non Exist | Non Exist Non_Exist 

Switch on N/A N/A N/A N/A N/A 
to Startup 

Initialization | N/A N/A N/A N/A 
Complete Not Ready 
Main Power | N/A Pes ee N/A 
On 

to Enabled to Enabled 

to Stopping 
Complete to Ready 
Startup to Startup | to Startup | to Startup | Startup to Startup 

Main Power Transition | Transition | Transition | Transition to | N/A 
Off to to Faulted | to Faulted | Faulted 

Not_Ready 
Fault Transition | Transition | Transition | N/A N/A 
Detected to Faulted | to to 

Fault_Stop | Fault_Stop 
Fault Stop |N/A N/A Transition to | N/A 
Complete Faulted 
Fault Reset |N/A N/A N/A N/A N/A N/A N/A Transition 
to 
Not_Ready 


5-29.5.1. 
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* See section 5-29.5.1 for further explanation of these events and how they are 
generated. 


Run/Stop Event Matrix 


Attribute 5, NetCtrl is used to request that Run Stop events be controlled from the network. The 
device however, has the option of inhibiting Run Stop events from the network, as the 
user/application may not allow Run Stop control from the network under certain circumstances. 
Only when attribute 15, CtrlFromNet is set to 1 by the device in response to a NetCtrl request, 
is Run Stop control actually accomplished from the network. 


If attribute 15, CtrlFromNet is 1, the events Run and Stop are triggered by a combination of the 
Run! and Run2 attributes as shown in the following table. Note that Run! and Run2 have 
different contexts for different device types. The following table shows the Run! and Run2 
contexts for the devices within the motor control hierarchy. 


2 Speed 


Drives and 
Servos 


RunFwd 
RunRev 


Runl 
Run2 
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If CtrlFromNet is 0, Run and Stop events must be controlled using local input(s) provided by 
the vendor. The Run and Stop events effect drive behavior as shown in the State Transition 
Diagram and the State Event Matrix. 


Runl 
0 jos Stop 

0-1 

0 2 

0-1 No Action 

1 = No Action 

1->0 


Important note: Local stop and run signals could override or be interlocked with the run/stop 
control through CIP. These are vendor specific features. Vendors should explain these 
interlocks and overrides in their product documentation. 


Fault and Warning codes 


This table lists the fault and warning codes used by AC Drives, DC Drives, and Servos for the 
‘Control Supervisor’ object. The source of the fault codes is the DRIVECOM Nutzergruppe 
e.V, which has granted permission to ODVA to use the fault codes in ODVA device profiles. 


Code Value [Hex] Meaning 

0000 No fault 

1000 General Fault 

2000 Current 

2100 Current, Device Input Side 
2110 Short Circuit/Short to Earth 
2120 Short to Earth 

2121 Short to earth in Phase L1 
2122 Short to earth in Phase L2 
2123 Short to earth in Phase L3 
2130 Short Circuit 

2131 Short Circuit in Phases L1 -L2 
2132 Short Circuit in Phases L2-L3 
2133 Short Circuit in Phases L3-L1 
2200 Current Inside the Device 
2211 Current inside the device, No. 1 
2212 Current inside the device, No. 2 
2213 Overcurrent during Startup 
2214 Overcurrent during Slowdown 
2220 Continuous Overcurrent 

2221 Continuous Overcurrent No. | 
2222 Continuous Overcurrent No. 2 
2230 Short Circuit/Short to earth 
2240 Short to earth 

2250 Short Circuit 

2300 Current, Device Output Side 
2310 Continuous Overcurrent 

2311 Continuous Overcurrent, No. | 
2312 Continuous Overcurrent, No. 2 
2320 Short Circuit/Short to Earth 
2330 Short to Earth 

2331 Short to Earth in Phase U 
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Code Value [Hex] 
2332 
2333 
2340 
2341 
2342 
2343 


3000 
3100 
3110 
3111 
3112 
3113 
3120 
3121 
3122 
3123 
3130 
3131 
3132 
3133 
3134 
3140 
3141 
3142 
3200 
3210 
3211 
3212 
3220 
3221 
3222 
3230 
3300 
3310 
3311 
3312 
3313 
3320 
3321 
3330 
3331 


4000 
4100 
4110 
4120 
4130 
4140 
4200 
4210 
4220 
4300 
4310 
4320 
4400 
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Meaning 

Short to Earth in Phase V 
Short to Earth in Phase W 
Short Circuit 

Short Circuit in Phases U-V 
Short Circuit in Phases V-W 
Short Circuit in Phases W-U 


Voltage 

Mains Voltage 

Mains overvoltage 

Mains overvoltage in phase L1 
Mains overvoltage in phase L2 
Mains overvoltage in phase L3 
Mains undervoltage 

Mains undervoltage in phase L1 
Mains undervoltage in phase L2 
Mains undervoltage in phase L3 
Phase Failure 

Failure of Phase L1 

Failure of Phase L2 

Failure of Phase L3 

Phase Sequence 

Mains Frequency 

Mains Frequency too high 
Mains Frequency too low 
Voltage inside the Device 
Overvoltage inside the device 
Overvoltage No. 1 

Overvoltage No. 2 
Undervoltage inside the Device 
Undervoltage No. 1 
Undervoltage No. 2 

Charging Error 

Output Voltage 

Output Overvoltage 

Output overvoltage in Phase U 
Output overvoltage in Phase V 
Output overvoltage in Phase W 
Armature Circuit 

Armature Circuit Discontinuity 
Field Circuit 

Field Circuit Discontinuity 


Temperature 

Ambient Temperature 

Excess Ambient Temperature 
Inadequate Ambient Temperature 
Ingoing Ambient Temperature 
Outgoing Air Temperature 
Device Temperature 

Excess Device Temperature 
Inadequate Device Temperature 
Drive Temperature 

Excess Drive Temperature 
Inadequate Drive Temperature 
Power Supply Temperature 
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Code Value [Hex] 


4410 
4420 


5000 
5100 
5110 
5111 
5112 
5113 
5120 
5200 
5210 
5220 
5300 
5400 
5410 
5420 
5430 


6000 
6010 
6100 
6200 
6300 
6301 
6302 
630F 
6310 
6320 


7000 
7100 
7110 
7111 
7112 
7113 
7120 
7121 
7200 
7300 
7301 
7302 
7303 
7304 
7305 
7306 
7307 
7310 
7320 
7400 
7410 
7420 
7421 
7422 
7423 
7500 
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... 630E 


Meaning 
Excess Supply Temperature 
Inadequate Supply Temperature 


Device Hardware 
Power Supply 

Low Voltage Power Supply 
+ 15V Power Supply 
+24V Power Supply 
+5V Power Supply 

DC Link Power Supply 
Control 

Measurement Circuit 
Computing Circuit 
Operator Control Circuit 
Power Section 

Output Stages 

Chopper 

Input Stages 


Device Software 

Software Reset (Watchdog) 
Internal Software 

User Software 

Date Set 

Data Set No.1 

from 2 to 14 accordingly 
Data Set No.15 

Parameter Loss 

Parameter Error 


Additional Modules 

Power 

Brake Chopper 

Brake Chopper Failure 

Brake Chopper overcurrent 
Brake Chopper Wiring 

Motor 

Motor Blocked 

Measurement Circuit 

Sensor 

Tacho defective 

Wrong Tacho Polarity 

Resolver | defective 

Resolver 2 defective 

Incremental Encoder 1 Defective 
Incremental Encoder 2 Defective 
Incremental Encoder 3 Defective 
Speed 

Position 

Computing Circuit 

Velocity Ramp Generation 
Trajectory Generation Error 
Invalid Parameters 

Trajectory Generator Precalculation 
Trajectory Interpolation 
Communication 
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Code Value [Hex] 
7510 
7520 
7600 


8000 
8100 
8110 
8111 
8112 
8113 
8114 
8115 
8116 
8120 
8200 
8300 
8302 
8311 
8312 
8313 
8321 
8331 
8400 
8401 
8402 
8500 
8501 
8502 
8600 
8611 
8612 
8700 
8800 


9000 


F000 
F001 
F002 
F003 
F004 
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Meaning 

Serial Interface No | 
Serial Interface No 2 
Data Memory 


Monitoring 
Communication 
Operational Data Monitoring 
No SYNC 
Synchronisation Fault 

No COMMAND 
COMMAND outside window. 
Cannot transmit ACTUAL 
ACTUAL outside window. 
Host Monitoring 

Closed Loop Control 
Torque Controller 

Torque Limiting 

Excess Torque 

Heavy Starting 

Standstill Torque 
Inadequate Torque 

Torque Breakage 

Speed Controller 

Velocity Following Error 
Velocity Limiting 

Position Controller 
Position Following Error 
Position Limiting 
Positioning Controller 
Following Error 

Reference Limit 

Synchro Controller 
Winding Controller 


External Malfunction 


Additional Functions 
Deceleration 

Inadequate Synchronisation 
Lifting Mechanism 

Open LOOP Control 
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5-30. AC/DC DRIVE OBJECT 
Class Code: 2Ahex 


This object models the functions specific to an AC or DC Drive. e.g. speed ramp, torque 
control etc. 


5-30.1. AC/DC Drive Class Attributes 


Need in Access Name Data Type | Description of 
Implementation | Rule Attribute 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


5-30.2. AC/DC Drive Instance Attributes 


Attribute Need in Access Name Data Type Description of Attribute 
ID implementation | Rule 


USINT _ [Number of Attributes supported 


Optional Get Attributes Array of | List of Attributes supported 
USINT 
3 Optional Get AtReference BOOL 1 = Drive actual at reference 
(speed or torque reference) based 
on mode 


4 Required Set/Get | NetRef BOOL _ | Requests torque or speed reference 
to be local or from the network. 
0 = Set Reference not DN Control 
1 = Set Reference at DN Control 
Note that the actual status of torque 
or speed reference is reflected in 
attribute 29, RefFromNet. 

5 Optional Set/Get | NetProc BOOL _ | Requests process control reference 
to be local or from the network. 
0 = Set Process not DN Control 
1 = Set Process at DN Control 
Note that the actual status of the 
process control reference is 
reflected in attribute 30, 
ProcFromNet. 


Semantics of 
Values 


Attribute 
ID 


N 


6 Required Set/Get | DriveMode USINT | 0= Vendor specific mode 
1 = Open loop speed (Frequency) 
2 =Closed loop speed control 
3 = Torque control 
4 = Process control (e.g. PI) 
5 = Position control 
7 Required Get SpeedActual INT Actual drive speed (best 
approximation) 
e SpeedScale 
Units: RPM / 2 
where SpeedScale is attribute 22 


8 Required Set/Get | SpeedRef INT Speed reference 
Units: RPM / 25?°4Seale 
where SpeedScale is attribute 22 
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Attribute Need in Access Name Data Type Description of Attribute 
ID implementation | Rule 


9 Optional Get CurrentActual INT Actual motor phase current 

Units: 100ma / 20u7enSeale 

where CurrentScale is attribute 23 
10 Optional Set/Get | CurrentLimit INT Motor phase current limit 

Units: 100ma/ 2°07" 

where CurrentScale is attribute 23 
11 Optional Get TorqueActual INT Actual torque 

Units: Nm / gr omunencale 

where TorqueScale is attribute 24 
12 Optional Set/Get | TorqueRef INT Torque reference 

Units: Nm / 7 TorqueScale 

where TorqueScale is attribute 24 
13 Optional Get ProcessActual INT Actual process control value 

Units: % / 2 ProcessSeale 

where ProcessScale is attribute 25 
14 Optional Set/Get | ProcessRef INT Process control reference set point 

Units: % / 7 ProcessSeale 

where ProcessScale is attribute 25 
15 Optional Get PowerActual INT Actual output power 

Units: Watts / 2Powesele 

where PowerScale is attribute 26 
16 Optional Get InputVoltage INT Input Voltage 

Units: Volts / gvollagescale 

where VoltageScale is attribute 27 
17 Optional Get OutputVoltage INT Output Voltage 

Units: Volts / 2 "eeseale 

where VoltageScale is attribute 27 


18 Optional Set/Get | AccelTime UINT Acceleration time 
Time from 0 to HighSpdLimit 
Units: ms / gee 
where TimeScale is attribute 28 
Acceleration time selection for 
negative direction is vendor 
specific. 

19 Optional Set/Get | DecelTime UINT Deceleration time 
Time from 0 to HighSpdLimit 
Units: ms / gee 
where TimeScale is attribute 28 
Deceleration time selection for 
negative direction is vendor 
specific. 


20 Optional Set/Get | LowSpdLimit UINT Minimum speed limit 

Units: RPM / 25PeedSeale 

where SpeedScale is attribute 22 
21 Optional Set/Get | HighSpdLimit UINT Maximum speed limit 

Units: RPM / 25PeedSeale 

where SpeedScale is attribute 22 


22 Optional* Set/Get | SpeedScale SINT Speed scaling factor. Scaling is 
accomplished as follows: 
ScaledSpeed = RPM / Oy aaa 
Range: -128 .. 127 
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Attribute Need in 

ID implementation 

: 
: 
. 
32 
i 
. 
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Set/Get 


Set/Get 


Set/Get 


Set/Get 


: 
° 


Set/Get 


Set/Get 
Set/Get 


Set/Get 
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Access 
Rule 


Data Type Description of Attribute 


TorqueScale 


SINT Current scaling factor. Scaling is 
accomplished as follows: 
ScaledCurrent = A / 2°U7e™'Seale 
Range: -128 .. 127 

Torque scaling factor. Scaling is 
accomplished as follows: 
ScaledTorque = Nm / pi onneeale 
Range: -128 .. 127 


n 


INT 


Set/Get | ProcessScale SINT Process scaling factor. Scaling is 
accomplished as follows: 
al ScaledProcess = % / 2P7oCessSeale 
Range: -128 .. 127 
Set/Get SINT Power scaling factor. Scaling is 


accomplished as follows: 
ScaledPower = W / 2°owerse*le 
Range: -128 .. 127 

Voltage scaling factor. Scaling is 
accomplished as follows: 
ScaledVoltage = V / geen 
Range: -128 .. 127 

Time scaling factor. Scaling is 


accomplished as follows: 
TimeScale 


VoltageScale SINT 
7 


ScaledTime = ms / 2 
Range: -128 .. 127 
Status of torque/speed reference 
0=Local torque/speed reference 
1=Network torque/speed reference 
Status of process control reference 
0=Local process reference 
1=Network process reference 
Selects Field Voltage or Field 
Current control for a DC Drive. 
0=Voltage Control (Open Loop) 
1=Current Control 

(Magnetizing field for DC drive) 
For voltage control of a DC Drive 
DC Drive Field Current set point. 
Units: Amps / CurrentScale 

where CurrentScale is attribute 23 
Enables/Disables field weakening 
for a DC Drive 

0=Disabled (DC Drive in current 
control) 

1=Enabled 


BOOL 


BOOL 


FieldlorV BOOL 


FieldVoltRatio 


FieldCurSetPt 


UINT 
UINT 


FieldWkEnable BOOL 


Get FieldCurActual INT Actual Field Current for a DC 
Drive. 
Units: Amps / CurrentScale 
where CurrentScale is attribute 23 
Set/Get | FieldMinCur INT Minimum Field Current for a DC 


Drive. 


Units: Amps / 2 


where CurrentScale is attribute 23 


CurrentScale 
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* See section 5-30.5.1. for scaling example. 


The basic units used by the AC/DC Drive Object are: 


Physical Quantity Units 


Speed: Revolutions Per Minute 
Current: 100 milliAmps 


Torque: m Newton Meters 


Process Goat rm | Percent 


% 
Power: W Watts 


N 
0 
Voltage: Volts 
Time: Milliseconds 


5-30.3. AC/DC Drive Common Services 


Service | Need in Implementation Service Name Description of Service 
Code 


OEhex Conditional* |Required | Get_Attributes_Single Returns the contents of the 
specified attribute. 


value. 

15hex n/a Optional | Restore Restores attribute values 
from a storage location 
accessible by the Save 
service. This service is 
only available if the drive 
is in the Ready or 
NOT_READY states. 

16hex /a 


n Optional | Save Saves all attribute values 
to a location accessible by 
the Restore service. 


5-30.4. AC/DC Drive Object Specific Services 


The AC/DC Drive object provides no object specific services. 
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5-30.5. AC/DC Drive Object Behavior 


6) DriveMode=1 


6) DriveMode=1,2 


Accel/Decel 
Circuit 
4 


6) DriveMode= 


8) SpeedRef [ 
(From network) ~<—\——e———_——————e 


Used when e 
4) NetRef = 1 other reference 
(not from network) 


Used when 
4) NetRef = 0 


« Frequency 


\ 6) DriveMode 


=2,4 


7) Speed Actual and/or 

9) CurrentActual and/or 
10) CurrentLimit and/or 
15) PowerActual and/or 
20) LowSpd Limit and/or 


18) AccelTime 6) DriveMode=5 
19) DecelTime 
20) LowSpdLimit 


P Ref ‘HighSpdLimi 
rocesshe 21) HighSpdLimit 


(From network) 


Used when g 
5) NetProc= 1 other reference 


(not from network} 13) Process Actual or 


Used when Other Process Feedback 
5) NetProc = 0 


Other Feedback 


Vendor specific position regulator 
algorithms (regulators, reference 
generators, etc. 


Position ref or 
commands 
(Vendor specific) 


The following drawing represents the signal flow in an AC drive whose output is an inverter 
frequency command. Signal flow is controlled by the AC/DC Drive Instance attributes shown 
in Bold type. The process and speed references can be directed to originate from network 
commands or from references internal to the drive or supplied to the drive through terminal 
blocks or keypads. Network control of these alternative reference sources will be vendor 
specific. The mode of operation can also be controlled from the network with the mode 
attribute AC/DC Drive object. Note that not all modes will be supported by all drives. 


The following drawing represents the signal flow for a AC or DC torque or current controlled 
drive. These drives can operate in Mode 3, allowing a network torque reference to directly 
control the drive. 


Each drive vendor can implement a process regulator and position regulator to feed either the 


speed regulator or the torque command directly. Broken lines indicate these alternative signal 
paths. 
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12) TorqueRef 
(From network) 


Used when 
4) NetRef =1 other reference 


(Not from network) 9) CurrentActual and/or 

Used when 10) CurrentLimit and/or 

4) NetRef = 0 11) TorqueActual and/or 
Other Feedback 


6) Mode=3 
6) DriveMode=1,2 
8) SpeedRef__,, | —, —— < Torque or 
(From network) “+———e——_—_——_____e current 
Used with ircuit |..-... \ 
4) NetRef=1 [other reference r ee EEE o— 6) Mode=2,4,5 


(Not from network) 


Used when ; 7) SpeedActual and/or i 
4) NetRef = 0 , is Fae 9) CurrentActual and/or : 6)Mode=5 
: 20) LowSpdLimit 11) TorqueActual and/or : |: 
6) DriveMode=4 _]; 21) HighSpdLimit : 15) PowerActual and/or 6) Mode=4 


20) LowSpdLimit and/or :‘ 
21) HighSpdLimit and/or : 
Other Feedback : 


14) ProcessRef 


(From network) 


Used when f 
5) NetProc = 1 other reference 


(Not from network)} 13) ProcessActual or 


Used when Internal Process Feedback 
5) NetProc = 0 


Broken lines 
indicate alternative 


signal paths. 


Vendor specific position regulator 
algorithms (regulators, reference 
generators, etc. 


Position ref or 
commands 
(Vendor specific) 


As illustrated below, AccelTime (attribute 18) is defined as the time in seconds it would take 
the drive to accelerate from zero to HighSpdLimit (attribute 21), the maximum speed at which 
the drive is allowed to operate. 


Similarly, DecelTime (attribute 19) is the time to slow down from HighSpdLimit (attribute 
21) to zero speed. 


There will be no guarantee that the drive will operate at these rates in actual applications, since 


current limit may increase the acceleration time, and lack of sufficient braking capability may 
increase the stopping time. 
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HighSpeedLimit 


AccelTime DecelTime 


<< << 


cM  — 
DecelTime 


AccelTime 


-HighSpeedLimit 


When DriveMode (attribute 6) is set to “1” or “2”, AtReference (attribute 3) is “1” when 
Speed Actual (attribute 7) is at its prescribed speed reference plus or minus a vendor specific 
hysteresis band. The vendor specific hysteresis band may be fixed, programmable, or zero. 


speed 


speed reference steresis band 


1 


AtReference 


0 
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When DriveMode (attribute 6) is set to “3”, AtReference (attribute 3) is “1” when 
TorqueActual (attribute 11) is at its prescribed torque reference plus or minus a vendor 
specific hysteresis band. The vendor specific hysteresis band may be fixed, programmable, or 
zero. 


torque 


torque reference vendor specific hysteresis band 


AtReference 


0 


5-30.5.1. Scaling of attribute values 
As part of the AC/DC Drive Object definition, engineeringunits are defined for each physical 
quantity, e.g. RPM for Velocity, Nm for Torque etc. To maximize the resolution capable or 
necessary on some devices or applications, these values can be normalized using a binary scale 
factor before transmission on the bus. A separate scaling factor is specified for each physical 
quantity. Normally, scaling factors will be set up once during initialization according to the 
range of values to be used in the application. 
Scaling Factors allow the representation of physical units on the bus to obtain an acceptable 
resolution and dynamic range for all applications. 


Example: Configuration of a DC Drive to operate with RPM resolution of 0.125 RPM 
SpeedRef (AC/DC Drive Object, Attribute ID 8) = 4567 
SpeedScale (AC/DC Drive Object, Attribute ID 22) = 3 


SpeedRef 4567 


=> Actual Commanded Speed = —— = = 570.875 RPM 
2 peedScale 23 


Input from Drive to bus: 

Actual Drive Operating Speed = 789.5 RPM 

SpeedScale (AC/DC Drive Object, Attribute ID 22) = 3 

=> SpeedActual (AC/DC Drive Object, Attribute ID 7) = Actual Operating Speed x 25Pe*S:a* 
= 789.5 x 2? = 6316. 


In cases where the applicable scaling factor attribute is non-zero, the units are: 
engineering unit 
2 Scale Factor Attribute ~ 


In the above example, therefore, the units are 0.125 RPM. 
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Drives that do not support scale factors (Attributes 22 ~ 28), should return an “Attribute Not 
Supported” error. In this case, the default scaling is presumed, and all physical quantities will 
then default to engineering units. For example, speed values will then default to units of RPM. 
Drives that do not use RPM as an internal measure should calculate an RPM value based on 
motor parameters. For example, AC VFD’s may calculate an RPM/Hz constant using motor 
rated frequency and motor base speed from theMotor Data Object. An example of this type of 
implementation (including scaling factors) for the commanded VFD’s frequency may be: 


SpeedRef x RatedFreq 
2 SpeedScale 


Frequency Command (Hz) = Saaaeusce 
x BaseSpee 


and an example implementation for the reported operating speed as a function of the output 
frequency may be: 

Output Frequency (Hz) x BaseSpeed x 2SPeedScale 
RatedFreq 


SpeedActual = Int 
Where: Frequency Command = the VFD’s resultant frequency command, the resolution of 
which is vendor-dependent. 

SpeedRef = AC/DC Drive Object Instance Attribute ID 8. 

RatedFreq = Motor Data Object, AC Motor Instance Attribute ID 9. 

SpeedScale = AC/DC Drive Object Instance Attribute ID 22. 

BaseSpeed = Motor Data Object, AC Motor Instance Attribute ID 15. 

SpeedActual = AC/DC Drive Object Instance Attribute ID 7. 


Int = A vendor-specific integer typecast function (such as rounding or 
truncation). 


Output Frequency = the VFD’s reported present operating frequency, the resolution of 
which is vendor-dependent. 
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5-31. ACKNOWLEDGE HANDLER OBJECT 
Class Code: 2Bhex 


The Acknowledge Handler Object is used to manage the reception of message 
acknowledgments. This object communicates with a message producing Application Object 
within a device. The Acknowledge Handler Object notifies the producing application of 
acknowledge reception, acknowledge timeouts, and production retry limit. 


§5-31.1. Class Attributes 


Need in Access Name Data Type Description of 
Implementation | Rule Attribute 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


Semantics of Values 


5-31.2. Acknowledge Handler Object Class Services: 
e Get_Attribute Single 
e Create 
e Delete 


Need in 


Name Service Description of Service 
Implementation Code 
Optional Get_Attribute_Single OEhex Used to read an Acknowledge Handler Object 
attribute value. 


Optional Used to create an Acknowledge Handler Object. 
Optional Delete O09hex Used to delete all dynamically created Acknowledge 
Handler Object instances. 


5-31.3. Acknowledge Handler Object Instance Attributes: 


Need in Access Name Data Description of Attribute 
Implementation Rule Type 


Required (Get) Get/Set Retry Limit | USINT Number of Ack Timeouts to | Range 0-255 
Optional (Set) wait before informing the default = 1 
producing application of a 


RetryLimit_Reached event. 


Required Set COS Connection Instance which Connection 
(Inactive) | Producing contains the path of the Instance ID 
Connection producing I/O application 
Get : Instance object which will be notified 
(Active) of Ack Handler events. 


Ack List Size 


Semantics of 
Values 


Acknowledge | UINT Time to wait for acknowledge | Range 1- 
before resending 65,535 ms (0 
invalid) 

default = 16 


Optional 


BYTE Maximum number of 0 = Dynamic 
members in Ack List 

>0 = Max 

number of 

members 
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Ack List List of active connection Number of 
instances which are receiving }| members 
Acks. followed by 
list of: 
Connection 
Instance ID 


6 | Optional Get Data with Ack Maximum number of 0 = Dynamic 
Path List Size members in Data with Ack 
Path List >0 = Max 
number of 
members 


5 | Optional 


7 | Optional Data with Ack List of connection Number of 
Path List instance/consuming members 
application object pairs. This | followed by 
attribute is used to forward list of: 
data received with Connection 
acknowledgment. Instance 
ID/CIP path 
length/CIP 
path 


e Ifthe specified value for the Acknowledge Timer attribute is not equal to an increment of 
the available clock resolution, then the value is rounded up to the next serviceable value. 
For example: a Set_Attribute_Single request is received specifying the value 5 for the 
Acknowledge Timer attribute and the product provides a 10 millisecond resolution on 
timers. In this case the product would load the value 10 into the Acknowledge Timer 
attribute. 

e The value that is actually loaded into the Acknowledge Timer attribute is reported in the 
Service Data Field of a Set_Attribute_Single response message associated with a request to 
modify this attribute. 

e A successful set attribute to the Retry Limit attribute will reset the Retry Counter. 

e ©The Ack List attribute is updated when an associated connection transitions between 
configuring, established, timed-out, and non-existent. Refer to the State Event Matrix for 
details. 

e Ifthe Acknowledge Handler Object is active (at least one member in the Ack List), the 
COS Producing Connection Instance attribute access is get only. 

e The default value loaded into the Acknowledge Timer attribute at time of instantiation is 16 
ms. 

e = The default value loaded into the Retry Limit attribute at time of instantiation is 1. 


5-31.4. Acknowledge Handler Object Instance Services: 
The Acknowledge Handler Object Instance supports the following Common Services: 


e Get_Attribute Single 
e Set_Attribute Single 
e Delete 


Need in Name Service Description of Service 
Implementation Code 


Get_Attribute_Single Used to read an Acknowledge Handler Object attribute 
value. 


Set_Attribute_Single Used to modify an Acknowledge Handler Object 
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a sr 
Used to delete an Acknowledge Handler Object 


5-31.5. Object-specific Services 


The Acknowledge Handler Object Instance also supports the following Object Class Specific 
Services: 


e Add AckData_ Path 
e Remove _AckData_ Path 


Need in Name Service Description of Service Service Request 
Implementation Code Parameters 


Optional Add_AckData_Path Adds a path for data with Connection Instance 
acknowledgment for a connected | CIP Path Length 


consumer. CIP Path 


Optional Remove_AckData_Path Removes a path with Connection Instance 


acknowledge path for the given 


connected consumer. 
These services are used to add and remove paths for each of the connected acknowledge 
consumers when data is sent with the acknowledgment. 


5-31.6. Behavior and Configuration of Acknowledged Data Production 


The following rules are used to configure and determine the behavior of an acknowledged 
Change of State or Cyclic I/O connection using the Acknowledge Handler Object. In the 
following examples, COS Producer is used to reference the device producing change of state or 
cyclic data and consuming an acknowledgment (client). COS Consumer is used to reference 
the device consuming the change of state or cyclic data and producing an acknowledgment 
(server). 


Acknowledged Data Production 


1. The COS Producers consumed connection path must be set to an available 
Acknowledge Handler Object. The path must consist of Class and Instance. If an 
Acknowledge Handler Object is not available, use the Acknowledge Handler Class 
Create service to obtain a new one. 


2. The COS Producers producing I/O application informs the Acknowledge Handler 
Object of new data production (Data Sent event message) or data production retries 
(Data Resent event message). 


3. The COS Producers acknowledgment reception is done by the Acknowledge Handler 
Object. The Acknowledge Handler object informs the Producing I/O application when 
one or more acknowledges have not been received within the acknowledge timeout 
(using the Ack List and Ack Timeout attributes). 
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10. 


11. 


The acknowledge message requires no data. The COS producing device’s 
Acknowledge Handler object should consider valid message reception as an 
acknowledgment. However, a change of state or cyclic producing device may be 
configured to consume data along with the acknowledgment. In this case the data is 
forwarded to the application object in the ‘Data with Ack Path List’ attribute, based on 
the connection which received the data. 


The COS Consumer acknowledge producing application should be configured to send 
either a zero length message or valid response (output) message when a valid input 
message is consumed. 


An acknowledge timer is started each time production occurs. The Acknowledge 
Handler object is notified of this event by a Data Sent or Data Resent event message 
from the producing application. 


Expiration of the acknowledge timer causes an Acknowledge Timout message to be sent 
to the producing application object. That object must resend the last message if the 
Retry Limit has not been reached. It may also take an application specific action. 


The retry count is incremented each time an Acknowledge Timeout message is sent to 
the producing application. When the retry limit has been reached, a Retry Limit 


Reached message is sent to the producing application object. 


The retry count is cleared on each Data Sent message. A Data Resent message does not 
clear the retry counter. 


The acknowledge timer value is configurable within the Acknowledge Handler object. 


The number of retries is (optionally) configurable within the Acknowledge Handler 
object. 


5-31.6.1. Change of State Examples 


Acknowledged Change of State (Using one connection object and one COS consumer) 


For the producer: 


1. 


2. 


Release 1.0 


Create a Connection Object. 


The producer transportClass_ trigger attribute is set to Class 2/3, Change-Of-State, 
Client (13h for Class 3) or Class2/3, Cyclic, Client (03h for Class 3). 


The produced connection path is set to the producing application which must support 
Change of State or Cyclic production. 


Create an Acknowledge Handler object. Configure the COS Producing Connection 
Instance’ attribute to the instance of the connection object which specifies the producing 
1/O application object. The Ack List attribute will be updated with the connection 
instance of the I/O connection object which is consuming an acknowledge as that 
connection transitions to the established state. Optionally configure the Acknowledge 
Timer and Retry Count attributes. 
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7. 


The consumed connection path is set to the Acknowledge Handler object just created 
and configured for handling the acknowledge. The path contains Class and Instance 
only. 


The consumed connection size is set to the size of the data expected to be delivered to 
the object specified in the consumed path of the Acknowledge Handler Object, or zero 


if no path is configured. 


All other attributes are configured the same way as any other peer to peer connection. 


For the consumer: 


8. 


10. 


11. 


The consumer transportClass_trigger attribute is set to Class 2/3, Server (83h for Class 
3}: 


The produced connection path is set to the consuming application (or some other 
application, this is product specific) for generating the acknowledge. 


The produced connection size is set to the size of the data to be delivered to the object 
specified in the consumed path of the change of state producing device’s Acknowledge 


Handler object, or zero if no path is configured. 


All other attributes are configured the same way as any other peer to peer connection. 


Acknowledged Change of State (Using multiple connection objects and COS consumers) 


For the producer: 


1. 


2. 
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Create a Connection Object. 


The producer transportClass_ trigger attribute is set to Class 0, Change-Of-State, Client 
(10h) or Class 0, Cyclic, Client (00h). 


The produced connection path is set to the producing application which must support 
Change of State or Cyclic production. 


The consumed connection path and consumed connection size are not configured. 
All other attributes are configured the same way as any other peer to peer connection. 
Create a Connection Object for each COS consumer. 


The consumer transportClass_ trigger attribute is set to Class 0, Server (80h) for each 
consuming connection object. 


Create an Acknowledge Handler object. Configure the COS Producing Connection 
Instance’ attribute to the instance of the connection object which specifies the producing 
1/O application object. The Ack List attribute will be updated with the connection 
instance of each I/O connection object which is consuming an acknowledge as those 
connections transition to the established state. Optionally configure the Acknowledge 
Timer and Retry Count attributes. 
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9. The consumed connection path for each consuming connection object is set to the 
Acknowledge Handler object just created and configured for handling the acknowledge. 
The path contains Class and Instance only 


10. The consumed connection sizes are set to the size of the data expected to be delivered to 
the consumed path set in the Acknowledge Handler Object, or zero if no path is 


configured. 


11. All other attributes are configured the same way as any other peer to peer connection. 


For each consumer: 


12. The consumer transportClass_trigger attribute is set to Class 2/3, Server (83h for Class 
3}: 


13. The produced connection path is set to the consuming application (or some other 
application, this is product specific) for generating the acknowledge. 


14. The produced connection size is set to the size of the data to be delivered to the 
consumed path set in the change of state producing device’s Acknowledge Handler 


object, or zero if no path is configured. 


15. All other attributes are configured the same way as any other peer to peer connection. 


Once the Connection Object(s) is (are) configured, an Apply Attributes service is sent to each 
configured Connection Object to transition the connection(s) to the Established state. During 
the apply, the connection object is delivered’ to both the consuming and producing application 
objects for validation of the attribute information. At this time, the producing I/O application 
checks for a change of state configuration by examining the transportClass_trigger attribute. If 
the Production Trigger bits are set to change-of-state or cyclic, the application will configure 
itself for change of state or cyclic production. If change of state or cyclic production is not 
supported by the producing application object an error must be returned to the apply_attributes 
service. 


Use of Timers with Acknowledged Data Production 


1. 


2: 


The following rules must be observed when sending acknowledged data. 


New data not sent while the Inhibit Timer is active (running). 


. New data is sent when no acknowledge is pending, subject to rule # 1. (An acknowledge is 


pending after a send of new data or a retry of old data and until an Ack Timeout or Ack 
Received. 


. Retry of old data occurs at Ack Timeout if new data is not available or the Inhibit Timer is 


active. 


. Sending new data (or old data on transmission trigger timeout) starts the Ack Timer, Inhibit 


Timer, and the Transmission Trigger Timer. The Retry Counter is also cleared. 


. Aretry of old data starts the Ack Timer. 
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Inactivity Timer = 4 x EPR 


Transmission Trigger Timer = EPR 


Production Inhibit Timer 


Ack 
Timeout 


Ack 
Timeout 


Typical Timing Relationships for Acknowledged Data Production 


Limit 


Inhibit Timer ‘Rie Inhibit Timer Ack Inhibit Timer 
c c 
Events Ack Timeout Expires Ack Timeout Received Expires Received Expires 


Received 


Input 


L: Dy: : 10: : eames : 10! 


Dataproueed FD ri: 


Acks consumed 


: Start: . : : = : Start: a : 
Actions eee "i Start: : ' af : Start: 
Inhibit Timer : 7 Inhibit Timer} Inhibit Timer 
. tart: 7 
Transmission Trigger Timer =! Ack Timer Add . Transmission Trigger Timer » Transmission Trigger Timer 
Inhibit Timer = . 
Start: i ‘ cae 
: Transmission Trigger Timer? : 
Ack Timer ;. Start: Start: 
Reset: : Ack Timer Ack Timer 
Retry Counter Start: Reset: Reset: 
Example COs system Ack Timer Retry Counter Retry Counter 
A A Reset: 
2 Acking devices Retry Counter 


The following diagrams illustrate the message flow in a Change of State connection for both single and 
multi-consumer configurations. 


Change-of-State Data 
or 
Cyclic Data 


Application 
end Response 


. 6 2 R Acknowledgd 
a . * : Handler |*** 
(PLC) Paar - : Object 


Acknowledge 


(Sensor) 


One Connection Object, One Consumer 
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Change-of-State or 
lic Data VO 


Application 


Application 


Acknowledge vo 


Responses ean ad Application 
Received a 


Acknowledge 


VO 


Application 


Application Vo 


Responge Application 


ror" ee 
© 


(Block I/O) 


Application 


end Response 
Acknowledge 


The following are the State Event Matrices for the Producing I/O application object and 
Acknowledge Handler object associated with a Change of State connection. 
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SEM for Producing I/O Application Object 


: Running 
Not Running with Acknowledgement Prohibited 


Change of State Ignore Event Inform Link Producer Inform Link Producer to Send Data Queue Event 
Detected to Send Data Send Data_Sent event message 
aE covet to Acknowledge Handler object 
tart it Timer ibit Ti 
Transition to Prohibited pane i ie congue 
Transition to Prohibited 


i Not Applicable Not Applicable Ignore Event If Ack_Active Set 
Acknowledge_Received Pp gn If Inhibit Timer not runing 


Transition to Running with 
Acknowledgement Else Set 
Ack Received flag Else 
Ignor Event 
Acknowledge Timeout | Ignore Event Not Applicable Inform Link Producer to Send Data Inform Link Producer to Send Data 


Send Data_Resent event message] Send Data_Resent event message 
to Acknowledge Handler object | to Acknowledge Handler object 


ae Inform Link Prod : Inform Link Producer to Send 
Transmission Not Applicable ; Send Th ; roducer Inform Link Producer to Send Data LAST Data Sent 
Ten Ge ADIrey ern ae Send Data_Sent event message | Send Data_Sent event message 
to Acknowledge Handler object | to Acknowledge Handler object 


Retry Limit Reached | Ignore Event Not Applicable Product specific Transition to Running with 
Acknowledgement 


If Ack Acti t 
Inhibit Timer Expires Ignore Event Not Applicable Not Applicable If ee aka 


Transition to Running with Ack 


Clear Ack_ Received flag 
Else Ignore Event 
Else Transition to Running 


Connection Deleted Not Applicable Transition to Not Running| Transition to Not Running Transition to Not Running 


Acknowledge_Active Set Ack Active flag | Transition to Running Ignore Event Set Ack Active flag 
with Acknowledgement 


Set Ack Active flag 


Acknowledge Inactive | Reset Ack_Active flag} Ignore Event Transition to Running Reset Ack_Active flag 
Reset Ack Active flag 


Connection Transition | If Ack Active Ignore Event Ignore Event Ignore Event 
to Established Transition to Running 

with Acknowledgement 

If Ack Inactive 

Transition to Running 


Note: This is a partial SEM for a producing I/O application object. Only those states and 
events associated with data acknowledgement are defined. Other states and events will most 
likely be associated with a producing I/O application object. 
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SEM for Acknowledge Handler Object 


Non-Existent 


Receive Acknowledge | Not Applicable 


Data_Sent Not Applicable 


Data_Resent Not Applicable 


Acknowledge Timer _| Not Applicable Ignore Event 
Expires 


Ignore Event 


Clear Ack Flag 

Forward any data to application object 

If all Acknowledges received 
Clear Ack Timer and Retry Counter 
Send Acknowledge_Received event 
message to producing application object 


Send Ack_Timeout event message to pro 


ducing application object 


Set Ack Required flag 
Set Ack Timer 
Clear Retry Counter 


Set Ack Required Flag and Ack Timer 

If Retry_Limit <> 0 

Increment Retry Counter 

If Retry Counter = Retry_Limit 
Send Retry_Limit_Reached event message 
to producing application object 


Transition to Inactive] Not Applicable Not Applicable 


Apply_Attributes Not Applicable 


Connection Transition |Not Applicable 
to Established 


Inactivity/Watchdog _ |Not Applicable 
Timer Expires 


Connection Deleted _| Not Applicable 


Release 1.0 


Verify new connection can be added to list 


Pass this message to the consumed ap 
plication object, if one is configured for 
this connection 


Add this connection instance to the con 
nection list (or internally flag as 'Acking') 


Pass this message to the consumed ap 
plication object, if one is configured for 
this connection 


Send Acknowledge_ Active event message 
to producing application 


Transition to Active 


Not Applicable 


Ignore Event 
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Verify new connection can be added to list 


Pass this message to the consumed application 
object, if one is configured for this connection 


Add this connection instance to the connection 
list 


Pass this message to the consumed application 
object, if one is configured for this connection 


Internally flag this connection as 'Not Acking'. 
An acknowledge will no longer be monitored 
for this connection, however it remains in the 
connection list. 


Pass this event to the consumed application ob 
ject, if one is configured for this connection 


If no 'Acking' connections in list send Ac 
knowledge_Inactive event to producing ap 
plication and transition to Inactive. 


Remove this connection instance from the 
connection list 


Pass this event to the consumed application ob 
ject, if one is configured for this connection 


If no 'Acking' connections in list send Ac 
knowledge_Inactive event to producing ap 
plication and transition to Inactive. 


5-185 


Chapter 5: Object Library Volume 1: CIP Common Specification 


5-32. OVERLOAD OBJECT 
Class Code: 2Chex 


This object models all the functions specific to an AC motor overload protection device. 


5-32.1. Overload Class Attributes 


Need in Access Name Data Type 
Implementation | Rule 


These class attributes are optional and are described in Chapter 4 of this specification. 


5-32.2. Overload Instance Attributes 


Attribute Need in Access Name Data Type Description of Attribute 
ID implementation | Rule 


1 USINT Number of Attributes supported 


Attribute 
ID 


Description of Attribute 


2 List of Attributes supported 
USINT 
3 Optional Set TripFLCSet | INT Overload Full Load Current Setting 
Units : 100ma / 2007enSeale 
ee el ae where CurrentScale is attribute 12 
4 Optional Set TripClass USINT Trip Class Setting 
a a Mie a 
5 Optional Get AvgCurrent |INT Average of the three phase current. 
Units: 100ma / 2007en'Seale 
ae il eal ll where CurrentScale is attribute 12 
fi Optional % Thermal Capacity 
8 Optional Get 


CurrentL1 Actual motor phase current L1 
CurrentScale 
Units: 100ma / 2 
where CurrentScale is attribute 12 
eo Units: 100ma / 2 
11 Optional Get GroundCurren | INT Ground Current 
t CurrentScale 
Units: 100ma / 2 
where CurrentScale is attribute 12 


INT 
9 Optional Get CurrentL2 INT Actual motor phase current L2 
CurrentScale 
where CurrentScale is attribute 12 
10 Optional Get CurrentL3 INT Actual motor phase current L3 
CurrentScale 
Units: 100ma / 2 
where CurrentScale is attribute 12 
12 Optional Set CurrentScale | SINT Current scaling factor. Scaling is 
accomplished as follows: 
CurrentScale 
ScaledCurrent = 100ma / 2 
Range: -128 .. 127 
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5-32.2.1. Scaling of attribute values 
As part of the Overload object definition, a separate scaling factor is specified current. To 
maximize the resolution capable or necessary on some devices or applications, current values 
can be normalized using a binary scale factor before transmission on the bus. Normally, this 
scaling factor will normally be set up once during initialization depending on the range of 
current values to be used in the application. 
CurrentScale allow the representation of current on the bus to be kept as short as possible 
while still preserving an acceptable resolution and dynamic range for all applications. 


Example: 


Output (to device from bus): 
TripFLCSet(Overload Object, Attribute ID 3) = 23456 


CurrentScale (Overload Object, Attribute ID 12) = 8 


=> Actual FLC setting used by device = TripFLCSet = 23456+ - 
= 91.625 100mA= 9.1625 amps 


Input (from drive to bus): 


Actual FLC setting used by device = 78.95 amps = 789.5 100mA 
CurrentScale (Overload Object, Attribute ID 12) = 3 
=> TripFLCSet(Overload Object, Attribute ID 3) = 789.5 x 2° = 6316 


Devices that do not support CurrentScale (Attributes 12), should return a zero, or not supported 
attribute error. In this case, the default scaling (0) is presumed. All currents will then default to 
units of 100ma. 


5-32.3. Overload Common Services 


Service Need in Service Name Description of Service 
Code Implementation 


OEhex Optional | Required | Get_Attributes Single Returns the contents of the 
specified attribute. 
10 n/a Required | Set_Attributes_Single Modifies an attribute value. 
hex q fe 


15hex n/a Optional | Restore Restores attribute values from 
a storage location accessible 
by the Save service. This 
service is only available if the 
drive is in the 
Ready_Disabled or 


Wait_Power states. 
Saves all attribute values to a 


16hex n/a Optional | Save 
location accessible by the 
Restore service. 


5-32.4. Overload Object Specific Services 


The Overload object provides no object specific services. 
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5-32.5. 


5-32.6. 


Overload Object Behavior 
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The Overload object behaviour can be changed by setting attributes, overload current setting 
and Trip Class setting will effect the trip curve of the device. 


Fault and Warning codes 


This table lists the fault and warning codes used by AC Motor Starter Device Profiles 


(Overload and Softstarter) 


Code Value 
0 


10 
ll 


20 
21 
22 
23 
24 
25 
26 
27 
28 
29 


40 
41 
42 
43 


50 
51 
52 
53 
54 
55 


60 
61 
62 
63 
64 


70 
71 
72 
2B 
74 
75 
16 
71 


Meaning 
NO FAULT 


TEST 
FORCE TRIP 


CURRENT TRIP 
THERMAL OVERLOAD 
PHASE LOSS 

PHASE LOSS - A 
PHASE LOSS - B 
PHASE LOSS - C 
PHASE IMBALANCE 
GROUND FAULT 

JAM 

UNDERLOAD 


CONTROL VOLTAGE 
CONTROL UNDERVOLTAGE 
CONTROL OVERVOLTAGE 
FREQUENCY 


MAIN VOLTAGE 
UNDERVOLTAGE 
OVERVOLTATGE 
IMBALANCE 
PHASE REVERSAL 
FREQUENCY 


HARDWARE 

ILLEGAL FLC SETTING 
MEMORY FAULT 
HARDWARE LINK FAULT 
NO DEVICE POWER 


MISC 

FAIL TO CLOSE 

FAIL TO OPEN 
STARTS/HOUR EXCEEDED 
LOW POWER FACTOR 
STATOR OVERTEMP 
BEARING OVERTEMP 
INCOMPLETE SEQUENCE 


* Note Fault Codes 101 to 255 are Vendor Specific Codes 
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5-33. SOFTSTART OBJECT 
Class Code: 2Dhex 


This object models all the functions specific to a Soft Start Motor Starter. 


§5-33.1. Softstart Class Attributes 


Need in Access Name Data Type 
Implementation | Rule 


These class attributes are optional and are described in Chapter 4 of this specification. 


Attribute 
ID 


Description of Attribute 


5-33.2. Softstart Instance Attributes 


eae Need in Access Name Data Description of Attribute 
implementation | Rule = 


2 Optional Attributes Array esr List of Attributes supported 
USINT 
3 


Required AtReference BOOL Starting/stopping output voltage 
reference status 
0 = Not At Reference 
1 = Output At Voltage Reference 


4 Required Set StartMode USINT |0=No Voltage Ramp 
No Current Limit 
1 = Voltage Ramp 
No Current Limit 
2 =No Voltage Ramp 
Current Limit 
3 = Voltage Ramp 
Current Limit 
4 - 9=Reserved by CIP 
10 - 255=Vendor Specific 
Optional Set StopMode USINT | 0 = Coast 
1 = Ramp Down 
2 = Brake 
3 - 9=Reserved by CIP 
10 - 255=Vendor Specific 
6 Optional Get/Set | RampMode BYTE 0 = Single Ramp 
1 = Dual Contiguous Ramp 
2 = Dual Independent Ramp 
3 - 9=Reserved by CIP 
10 - 255=Vendor Specific 


Nn 


7 Optional Get/Set | RampTimel UINT Tenths of Seconds 
8 Optional Get/Set | Initial Voltage1 USINT | 0- 100 % Of Full Line Voltage 
RampTimed [UINT | Teths of Second 


10 InitialVoltage2__ [USINT [0 - 100 % of Full Line Voltage 


11 Optional Get/Set | Rotation BOOL 0 = ABC phase rotation 
1 = CBA phase rotation 
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Attribute Need in Access Name Data Description of Attribute 
ID implementation | Rule Type 
12 Optional Get/Set | KickStart BOOL 0 =disabled 
= enabled fixed time 


13 KickStartTime __ |USINT _| Tenths of Seconds 
14 KickStartVoltage 0 - 100 % of Full Line Voltage 


15 Optional Get/Set | EnergySaver BOOL _ | 0 =disabled 
1 = enabled 


17 Optional Get/Set | CurrentLimitSet UINT Percent of Rated Current (Motor 
18 Optional Get/Set | BrakingCurrentSet | UINT Percent of Rated Current (Motor 
5-33.3. Softstart Common Services 


Service Need in Service Name Description of Service 
Code Implementation 


OEhex Optional | Required | Get_Attributes Single Returns the contents of the 
specified attribute. 


10hex Set_Attributes_Single Modifies an attribute value. 


15hex n/a Optional | Restore Restores attribute values from 
a storage location accessible 
by the Save service. This 
service is only available if the 
drive is in the 
Ready_Disabled or 
Wait_Power states. 

16hex n/a Optional | Save Saves all attribute values to a 
location accessible by the 
Restore service. 


5-33.4. Softstart Object Specific Services 


The Softstart object provides no object specific services. 


5-33.5. Softstart Object Behavior 
5-33.5.1. Starting Behavior 


The controlled starting of motors can be accomplished using one or more optional approaches; 
Voltage Ramp (single ramp, dual contiguous ramp, or dual independent ramp options), Current 
Limit, or a combination of Voltage Ramp /Current Limit. 


StartMode (Attribute 4) configures the device to Voltage Ramp / Current Limit starting 
behavior. 
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5-33.5.1.1. 


5-33.5.1.2. 


5-33.5.1.3. 


Release 1.0 


Voltage Ramp Starting 


Voltage Ramp based starting (with no current limiting) is selected by setting the StartMode 
(Attribute 4) to a value of “1”. The mode in which the voltage is ramped up is selected by 
RampMode (Attribute 6). 


When RampMode (Attribute 6) = 0, Single Ramp mode is selected. In this mode the output 
voltage of the Soft Starter is increased at a fixed rate, over a user defined time period, 
RampTimel (Attribute 7), until it reaches the full line voltage rating of the softstart. To over 
come motor/load inertia, the output voltage may be set to higher than zero voltage, 

Initial Voltage! (Attribute 8) before the voltage ramp up is started. For very high load inertia 
situations, the full line voltage can be applied for a fixed period of time: KickStart (Attribute 
13) is set to 1, or optionally a user defined voltage (specified as a % of full line voltage) for a 
user defined period of time: Kick Start (Attribute 13) is set to 1 , KickStartTime (Attribute 12) 
(greater than zero), and Kick Start Voltage (Attribute 18) (greater than zero) values are entered. 


When RampMode (Attribute 6) = 1, Dual Contiguous Ramp mode is selected. In this mode 
the output voltage is increased at a fixed rate, over a user defined time period, RampTime1 
(Attribute 7), until it reaches Initial Voltage2 (Attribute 10). The output voltage then increases 
at a different fixed rate, over a second user defined time period, RampTime2 (Attribute 9), until 
it reaches full line voltage. As in single ramp soft starters, the first ramp of a dual contiguous 
ramp soft starter may be preceded with Initial Voltagel and/or Kick Start functions. 


When RampMode (Attribute 7) =2, Dual Independent Ramp mode is selected. In this mode 
the user can use the Run! (Control Supervisor Attribute 3) and Run2 (Control Supervisor 
Attribute 4) commands to alternate between 2 pre downloaded single ramp starting profiles. 
The use of the Run! attribute, starts the motor using the RampTime! and Initial Voltage] 
values . The use of the Run2 attribute, starts the motor based on the RampTime2 and 

Initial Voltage2 values. All other Ouput Configuration Attributes are common to both ramps, 
except for potential vendor specific settings of the StopMode (see Stopping Behavior section). 


Current Limit Starting 


Current Limit based starting (with no voltage ramp) is selected by setting the StartMode 
(Attribute 4) to a value of “2”. In this case the output voltage is increased until the motor 
current equals the CurrentLimitSet (Attribute 16). The voltage is then maintained at a level 
that does not allow the current Limit to be exceeded , until either full speed is reached (and 
motor current drops below the CurrentLimitSet) or until the overload is tripped. The Current 
Limit may only be exceeded during operation of the Kick Start function. 
CurrentLimitSet(Attribute 16) is entered as a percent of the Motor Data Object Instance 
attribute RatedCurrent (Attribute 6) value. 


Voltage Ramp With Current Limited Starting 


Voltage Ramp with Current Limit based starting is selected by setting StartMode (Attribute 4) 
to a value of “3”. In this case the output voltage increases according to the selected voltage 
ramp until the CurrentLimitSet (Attribute 16) is reached. At this point, the output voltage stops 
increasing and current limit based starting continues until either full speed is reached (and 
motor current drops below the CurrentLimitSet) or until the overload is tripped. 


CurrentLimitSet(Attribute 16) is entered as a percent of the Motor Data Object Instance 
attribute RatedCurrent (Attribute 6) value. 
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5-33.5.2. 


5-33.5.2.1. 


5-33.5.2.2. 


5-33.5.2.3. 


5-33.5.2.4. 


5-33.5.3. 
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Stopping Behavior 


Several optional Stop Modes; Coasting, Ramp Down, DC Braking, or Vendor Specific may be 
selected via StopMode (Attribute 5). The Stop Mode chosen is independent of the devices 
Start Mode setting. 


Coasting to Stop 
In this mode, the soft starter sets the output to zero volts, and the motor “coasts” to stop. 
Ramp to Stop 


In this mode, the output voltage is decreased at a fixed rate from line voltage to zero volts over 
the user defined time period Decel Time (Attribute 16). 


DC Brake to Stop 


For fast motor stopping, a DC braking current is applied to the motor for the duration of the 
DecelTime (Attribute 15). The amount of DC braking current applied to the motor is specified 
in BrakingCurrentSet (Attribute 17). BrakingCurrentSet (Attribute 17) is entered as a percent 
of the Motor Data Object Instance attribute RatedCurrent (Attribute 6) value. 


Vender Specific Stopping 


In this mode, the soft starter stops the motor by setting the output voltage according to a profile 
unique to a particular vendor. 


Other Attribute Behaviors 

Rotation (Attribute 11) 

Sets the main voltage. phase rotation sequence for Phases A,B & C. 

EnergySaver (Attribute 14) 

Sets whether the energy saver function is active when the motor is operating at reference. The 
energy saving function works as follows: When a motor is operating under a loaded condition 
and then the load is reduced, the current the motor draws will decrease. The energy saver 
function lowers the voltage to a point where the current starts to increase again. The output 


voltage is maintained at that level until the load increases, in which case the soft starter will 
increase the output voltage back up to the line voltage level. 


Soft Starter Output Voltage Behavior Description 
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Example: Dual Contiguous Ramp Soft Start With Ramp Down Stop Mode 
Output Voltage 


Full Line Voltage 
Kick Start Voltage 


Ramp2 Initial Voltage 


Running at 
Reference 


Ramp1 Initial Voltage 


Kick 
Start Time 
Time 


Example: Dual Independent Ramp Soft Start With Ramp Down Stop Mode 


Output Voltage 


Ramp Profile Based on “Run1” Ramp Profile Based on “Run2” 


Full Line Voltage § - - - - — — — — — — — pm - ee 
Kick Start Voltage 


Ramp2 Initial Voltage 


Running at Running at 
Reference Reference 


Ramp1 Initial Voltage 


Kick' Ramp 1 Decel Kick! Ramp 2 Decel Time 
Start Time Time Start Time Time 
Time Time 
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5-33.6. Fault and Warning codes 
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This table lists the fault and warning codes used by AC Motor Starter Device Profiles 


(Overload and Softstarter) 


Code Value 
0 


10 
11 


20 
21 
22 
23 
24 
25 
26 
27 
28 
29 


40 
41 
42 
43 


50 
51 
52 
53 
54 
55 


60 
61 
62 
63 
64 


70 
71 
72 
2B 
74 
75 
16 
77 


Meaning 
NO FAULT 


TEST 
FORCE TRIP 


CURRENT TRIP 
THERMAL OVERLOAD 
PHASE LOSS 

PHASE LOSS - A 
PHASE LOSS - B 
PHASE LOSS - C 
PHASE IMBALANCE 
GROUND FAULT 

JAM 

UNDERLOAD 


CONTROL VOLTAGE 
CONTROL UNDERVOLTAGE 
CONTROL OVERVOLTAGE 
FREQUENCY 


MAIN VOLTAGE 
UNDERVOLTAGE 
OVERVOLTATGE 
IMBALANCE 
PHASE REVERSAL 
FREQUENCY 


HARDWARE 

ILLEGAL FLC SETTING 
MEMORY FAULT 
HARDWARE LINK FAULT 
NO DEVICE POWER 


MISC 

FAIL TO CLOSE 

FAIL TO OPEN 
STARTS/HOUR EXCEEDED 
LOW POWER FACTOR 
STATOR OVERTEMP 
BEARING OVERTEMP 
INCOMPLETE SEQUENCE 


* Note Fault Codes 101 to 255 are Vendor Specific Codes 
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5-34. SELECTION OBJECT 
Class Code: 2Ehex 


The Selection Object manages selection and distribution of I/O messages from the 
Connection Object to internal Application Objects. 


5-34.1. Class Attributes 


Need in Access Name Data Type Description of 
Implementation | Rule Attribute 


These class attributes are optional and are described in Chapter 4 of this specification. 


Number Semantics of Values 


Reserved for CIP 


Optional Get Max number Indicates maximum _ | Range 0 — 65535. 
of instances number of instances 
supported. 


5-34.2. Class Services 


Service Need In Service Name Service Description 
Code Implementation 


O8hex Used to instantiate a next instance of the class. 

O09hex Used to delete all instances of class. 

O6hex Used to start all instances of class 

O7hex Used to stop all instances of class. 

O5hex Used to reset all instances of class. Clear table entries. 
OEhex Used to read a class attribute value. 


*This Service is REQUIRED if any Class attributes are supported. 


5-34.3. Instance Attributes 
Attr Need in Access Attribute Name Data Attribute Semantics of 
ID Implementation Rule Type Description Values 
1 Required Get State USINT | State of the object. | See attribute 
description. 


2 Required Get Max_ destinations Indicates Range 0-65535. 
maximum number 
of destination 
indexes supported. 


ions of destination_list. 
4 Destination_list Array Path := SEQUENCE | Path length, Path. 
of Path | OF { See Appendix C 
[ USINT pathlength; for encoding. 
Array of USINT]} 
5 Required Get Max_Sources UINT Indicates Range 0-65535. 
maximum number 
of source indexes 
supported. 


6 Required Get Number_of sources | UINT Number of entries Range 0-65535. 
of source_list. 


7 Required Set Source_list Array Array of Connection 
of consuming I/O Instance IDs. 
UINT Connection 
Instance IDs. 


8 Range 0-65535 


Release 1.0 Open DeviceNet Vendor Assoc. & ControlNet International 5-195 


Chapter 5: Object Library 


Need in Access Attribute Name Data Attribute 
Implementation Rule Type Description 


5-196 


Attr 


10. 


source_list array 
indicating which 
source is currently 
being used. 
Indicates sources 
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Semantics of 
Values 
where one (1) is 
first entry in 
source_list. 


0 = Available, 


1 = Not available, 
Default values are 


that are not 
available. 


9 Optional Get Source_Alarm 
of 
all 0. 
10 Optional Get/Set | Algorithm _Type USINT | The selection If not supported, 
algorithm type. algorithm_type 
=0. 
Range 2-255. 


11 Conditional Get/Set | Detection Count USINT | Required when 
supported. 4. 

12 Conditional Get/Set | Selection Period UINT Required when Range 1-65535 
supported. 


(ms). 
state - Defines the current state of the Selection Object instance. The table below defines 
the possible states and assigns a value used to indicate that state. 


Values assigned to the state attribute 


State Name Description 
| 00 | Non-existent | The Selection Object does not exist. 


01 Idle The Selection Object does not distribute messages and the 
internal selection algorithm is not active. 
02 Running The Selection Object distributes messages and internal 
selection algorithm is running. 
max_destinations - Maximum number of destination paths managed by the Selection 
Object. 


number_of_destinations - Number of destination paths managed by the Selection Object. 
Default value is zero(0). 


destination_list - This attribute is an array of paths to objects which receive messages from 
the Selection Object. See Volume I, Appendix I. All members in the list must be unique. 


max_sources - Maximum number of source paths managed by the Selection Object. 


number_of_sources - Number of source paths managed by the Selection Object. Default 
value is zero(0). The number_of sources and number_of destinations do NOT have to be 
equal. 


source_list - This attribute is an array of Consuming Connection Instance IDs which send 
messages to the Selection Object. All members in the list shall be unique. 


source_used - This attribute is used to indicate the source of a message which is selected 
by the Selection Object. The value of this attribute indicates the index into source _list 
currently in use. A value of zero (0) indicates no source is currently being used. 


source_alarm - This attribute is used to indicate which sources are available. Size of the 
array is equal to the value of the max_source attribute. 


algorithm_type - Defines the algorithm types. All four algorithm types are required if this 
attribute is supported. If this attribute is not supported, then all messages pass through. See 
table below. 
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Values assigned to the algorithm_type attribute 


CS 
fe | 
a _| 
rect _| 
fcr _| 


© 
vendorspaife sf SCSC~C~SY 


11. detection_count - The parameter used by algorithms which require a counter. 


12. selection_period - The parameter used by algorithms which require a time interval. 


5-34.4. Instance Services 


Service Need In Service Name Service Description 


Code Implementation 


OEhex Get_Attribute_Single Used to read a Selection Object attribute value. 
U 


10hex Set_Attribute_Single sed to modify a Selection Object attribute 
value. 


O6hex Used to start a Selection Object. 
O09hex Used to delete a Selection Object. 
18 hex Used to get values of a member in an array. 
U 
U 
U 


sed to stop a Selection Object. 


sed to reset a Selection Object. Clear paths. 


19 hex sed to set values to a member in an array. 


sed to insert or add a member to an array. 


sed to remove a member from an array. 
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The behavior of the Selection Object, while in the RUNNING state, is dependent upon the 


algorithm_type attribute. 


The Selection Object State Transition Diagram 


Power Up AND 
No Configuration 


Create OR 
Configuration Invalid 


Insert Member / 
Remove Member / 
Get Attribute Single / 
Set Attribute Single 


Send Message / 
Receive Message / 
Insert Member / 
Remove Member / 


NON-EXISTENT 


Power Up AND 
Configuration Invalid 


Configuration Valid 


Get Attribute Single / RUNNING 


Set Attribute Single 


State Event Matrix for Selection Object 


Create Class instantiates a 
Selection Object. Set 
default values. 
Transition to Idle. 


Power Up & Transition to Not applicable. 
Configuration Valid | Running. 


Delete Error: Object does not 
exist. 


Start Error: Object does not 
exist. 


Stop Error: Object does not 
exist. 


Reset Error: Object does not 
exist. 


Receive_ Message Not applicable 
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Not applicable. 


Release all associated 
resources. Transition to 
Non-existent. 


If attributes are valid, 
Transition to Running. 


Error: The object cannot 
perform the requested 
service in its current 
mode/state. 


Error: Set default values. 


Discard the message. 


Delete 


Running 


Not applicable. 


Not applicable. 


Release all associated resources. 
Transition to Non-existent. 


Error: The object cannot 
perform the requested service in 
its current mode/state. 


Transition to Idle. 


Discard all received messages. 
Set default values. Transition to 
Idle. 


When a message is received 
from a Connection Object, check 
source_list attribute and update 
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Event 


Remove_ Member 


Insert_ Member 


Get_Attribute_ 
Single 
Set_Attribute_ 


Single Get_Member 


Set_Member 


Error: Object does not 
exist. 


Error: Object does not 
exist. 


Error: Object does not 
exist. 


Selection Object Attribute Access 


Attribute 
State 


max_destinations 


number_of destinations 


destination_list 
max_sources 
number_of sources 
source_list 
source_used 
source_alarm 
algorithm_type 
detection_count 


selection_period 


Not available 


Message Distribution 


Remove one member from 
source_list or 

destination _list attribute. 
Subtract one (1) from 
number_of sources or 
number_of_ 


destinations attribute value. 


Insert or add one member 
to source_list or 
destination_list attribute. 
Algorithm type shall 
determine usage of 
members in array. 


Validate/service the request 
based on internal logic and 
per the Access Rules. 
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Running 


source_used (if applicable). See 
algorithm_type for details. If 
fault detected, set appropriate 
source index bit in source_alarm 
attribute. 


Remove one member from 
source_list or destination_list 
attribute. Subtract one(1) from 
number_of sources or 
number_of destinations attribute 
value. 


Insert or add one member to 
destination _list attribute. Add 
one(1) to number_of_ 
destinations attribute value. 


A member cannot be added to 
source_list attribute. In this case, 
return error. 


Validate/service the request 
based on internal logic and per 
the Access Rules. 


Running 


Get/Set/Insert/Remove 


The Selection Object manages distribution of messages. This function provides multicast 

communication among Application Objects. The following diagram illustrates the message 
flow of this Multicast Communication. 
The Selection Object receives a message from a Connection Object and delivers this message 
to Application Object(s). 
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I/O Message Distribution 


Message ID=1 
Source 
ei ba 


Identifier = 0 0001 000001, 


Message 


Object Object 


Node #1 


Node #2 


Message Selection 


The Selection Object may produce one output message from multiple input messages. This 
function may be used for redundant node applications. The Selection Object selects one 
message from more than one message based on its internal algorithm. 


In high reliability systems, there is a requirement for redundant nodes. The Selection Object 


receives messages from redundant nodes and selects one message based on an internal selection 
algorithm. 
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Message Selection Example 
Message ID=1 


Source 
MAC ID=1 


Identifier = O OO01 000001, 
Data=1 


Message 


Node #1 


Node #3 


ae ee 
Message 


Node #2 \—__ Identifier = 0 0010 000010, 
Data=1 


Selection Algorithm 


Same Input 
Source 


M ID=2 
a MAC ID=2 


The following algorithms are currently defined for message selection. 


e Pass Through 
e Hot Backup 
e First Arrival 


Pass Through 
No algorithm. Forward all arriving messages to destination(s). 


Hot Backup 

This algorithm is shown in the Figure labeled Hot Backup. Node #1 is higher priority than 
Node #2. Node #3 normally accepts messages from Node #1. Node failure is detected in the 
following manner. If the Selection Object detects that Node #1 failed, it accepts messages from 
Node #2 and forwards them to Application Object(s). Upon the receipt of the message from 
Node #2, the “Message Counter” within the Selection Object is incremented by one. If the 
message from Node #1 is received, the “Message Counter’ is reset. If the number of the 
“Message Counter” reaches detection_count (N), the Selection Object detects that Node #1 
failed. If Node #1 recovers and resumes sending messages, the Selection Object accepts 
messages from Node #1. “N” is the configurable maximum count and set in attribute 12. If 
“number of sources”, attribute 7, equals two(2) then the first member in the “source list”, 
attribute 8, has the higher priority. 
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Hot Backup 
Node 
#1 


--- Fault---, -- Recovery 


#2 


Message, 19 1 0 OF 1 2«N 0 


Counter * 
X: Accept, - : Discard, Deféct 
N: detection_count 


5-34.5.5. First Arrival 


This algorithm is shown in the Figure labeled First Arrival. The Selection Object within Node 
#3 always accepts the first arriving message from either of the two nodes; Node #1 or Node #2. 
Upon receipt of the first message from an active node, the “Message Counter” within the 
Selection Object is incremented by one. The “Message Counter” is decremented each time a 
message is received from the alternate node. If the number within the “Message Counter” 
reaches “detection count”, attribute 12, the Selection Object detects that a node failed. The 
node to which the positive count is associated determines the node from which the Selection 
Object forwards the message. “N” is the configurable maximum count contained within 
attribute 12. The “number of sources”, attribute 7, equals two(2). See the Figure labeled 
Behavior of First Arrival in “Running State” for detail behavior. 


First Arrival 


Node 323 Raulbess 
#1 


- - Recovery - 


#2 

#3 

M Nea EXE OX = x x x x x x x 
Cae ee i oe Ar ih. 0 1 Qe N 0 0 O 1 0 
ounter 


X: Accept, -: Discard, N: detection_count 
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Behavior of First Arrival in “Running State” 


Node #1 FAULTED and Node #2 ACTIVE 


IF Counter = detection_count AND 
Msg Received from Node #2 THE 
Forward Node #2 Msg 

Set Counter=0 

Counter STOP 


IF Msg Received from Node #2 THEN IF Msg Received from Node #1 AND Transition to 
Counter ++ Counter>0 THEN Running 
Forward Node #2 Msg Counter -- Meg Received trom Nodew? 


= LL | Counter = | 
Node #2 ACTIVE 


Forward Node #2 Msg 
IF Counter = 0 AND IF Counter = 0 AND 
Msg Received from Node #2 THE Msg Received from Node #1 THEN 
Forward Node #2 Msg Forward Node #1 Msg 


Set Counter=1 Set Counter=1 
Msg Received from Node #1 


Node #1 ACTIVE 
Wes = Counter = 1 


IF Msg Received from Node #1 THEN IF Msg Received from Node #2 Aes Rode Mss 


Counter ++ Counter>0 THEN 
Forward Node #1 Msg Counter -- 


IF Counter = N AND 
Msg Received from Node #1 THE 
Forward Node #1 Msg 


THEN 
Set Counter=0 Counter ACTIVE 
Counter STOP 


Node #2 FAULTED and Node #1 ACTIVE 


5-34.5.6. Last Arrival 


IF Msg Received from Node #1 
THEN 
Counter ACTIVE 


IF Msg Received from Node #2 


This algorithm is shown in the Figure labeled Last Arrival. The Selection Object starts a timer 
when transmits to running. It forwards the last message received when the timer expires, and 
immediately restarts the timer. If no message is received AND the timer expires, the Selection 
Object does not forward a message to the Application Object(s). The “selection period” which 
is shown as “dt” in the figure is the value contained in attribute 13. The “number_of_ sources”, 
attribute 7, is equal to two(2) in the example. 

Last Arrival 


Node 
#1 


#2 


#3 


N 
X: Accept, -: Discard Detect 
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Examples 


I/O Message Distribution 


Application 
Object [1] 


DataA 
(Path2) 


Selection 
Object [6] 


Connection 
Object [10] 


Application 
Object [2] 


Application 
Object [3] 


CID: Connection ID 


Attribute Attribute Name Attribute Value 
Number 


Ee 
ee 
[fs Yaouceaem Sd 
a 


I/O Message Selection 


Attribute Attribute Name Attribute Value 
—s 


a 
destination_list {Path1} 


fs [number ofsonees 
a 
sous atm SOO 
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NOTE: 
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S-DEVICE SUPERVISOR OBJECT 
Class Code: 30hex 


This object models the interface, functions and behavior associated with the management of 
application objects for devices within the “Hierarchy of Semiconductor Equipment Devices”. 
Throughout this CIP Standard, objects belonging to this hierarchy are identified as such by a 
naming convention that includes a prefix of “S-” in the object class name. This “Hierarchy of 
Semiconductor Equipment Devices” is completely defined in this object definition such that all 
objects belonging to this hierarchy require the existence of an S-Device Supervisor object to 
manage its functions and behaviors. 


The S-Device Supervisor object centralizes application object state definitions and related 
status information, exception status indications (alarms and warnings), and defines a behavior 
model which is assumed by objects identified as belonging to the Hierarchy of Semiconductor 
Equipment Devices. That is, if a reset is requested of the S-Device Supervisor object instance, 
it will be performed by this object instance as well as all of its associated application objects. 


Similarly, the Identity object provides an interface to the S-Device Supervisor object. A reset 
request to the Identity object (of any type) causes a reset request to the S-Device Supervisor 
object. Further relationships are specified in the Behavior section below. 


Additionally, some device attributes are defined which are required in order to specify device 
models such that they are compliant with the SEMI S/A Network Standard*, from which the 
Hierarchy of Semiconductor Equipment Devices is derived. Objects defined to exist within the 
Hierarchy of Semiconductor Equipment Devices are done so in order to simplify the 
management and description of object behavior while insuring compliance with the SEMI 
Standard. 


By association with this object, the Start, Stop, Reset, Abort, Recover and Perform_Diagnostic Services are 
inherently supported by all objects within the Hierarchy of Semiconductor Equipment Devices. Although, for the 
associated application object instances, these services are not accessible over the network. 


* Semiconductor Equipment and Materials International, Mountain View CA, Standard E54: 
Sensor/Actuator Network Common Device Model. 
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S-Device Supervisor Class Attributes 


Need in Access Name Data Type 
implementation | Rule 


These class attributes are optional and are described in Chapter 4 of this specification. 
Reserved by CIP for Future Use 


Attribute 
ID 


Description of Attribute 


99 


Identifies a subset of additional 
class attributes, services and 
behaviors. 


Conditional * Subclass 


* If the value of Subclass is 00 which identifies "no subclass", then this attribute is 
OPTIONAL in implementation, otherwise, this attribute is REQUIRED. 


Subclasses 


Each class level subclass defines a unique meaning for an overlapping range of class attribute 
IDs and/or class service IDs. The range for subclass definitions begins at ID 96 and numbers 
downward for attributes, and ID 63,,., and numbers downward for services. The subclass for a 
given class is identified by the value of its Subclass class attribute. The subclasses for this 
object are specified at the end of this object specification section. 


S-Device Supervisor Instance Attributes 


CIP reserves Attribute ID 100-199 (64e.-C7hex) for Vendor Defined Attributes. See Volume I, 
Chapter 4 for more information on Object Definitions. 


Attr Need in Access | NV Name Data Type Description of Attribute 
ID |implementation | Rule 
1 |Optional Get | NV |Number of USINT Number of Attributes supported by 
Attributes the object instance 
2 {Optional Get | NV |Attribute List Array of List of attributes supported by the 
USINT object instance 
3 {Required Get | NV |Device Type SHORT ASCII Text, Max. 8 Characters, see 
STRING “Semantics” section 
N 
For this revision, this attribute must 


4 |Required Get V |SEMI Standard |SHORT Specifies the revision level of the 
Revision Level 
be: “E54-0997” 


STRING SEMI S/A Network Standard to 
which the device complies. 
5 |Required Get | NV |Manufacturer’s |SHORT ASCII Text, Max. 20 Characters, 
Name STRING see “Semantics” section 
6 |Required Get | NV |Manufacturer’s |SHORT ASCII Text, Max. 20 Characters, 
Model Number |STRING Manufacturer Specified 


7 {Required Get | NV |Software SHORT ASCII Text, Max. 6 Characters, see 
Revision Level |STRING “Semantics” section 
8 {Required Get | NV |Hardware SHORT ASCII Text, Max. 6 Characters, see 
Revision Level |STRING “Semantics” section 
9  |Optional Get | NV |Manufacturer’s |SHORT ASCII Text, Max. 30 Characters, 
Serial Number |STRING Manufacturer Specified, see 
“Semantics” section 
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Attr Need in Access | NV Name Data Type Description of Attribute 
ID | implementation | Rule 
10 {Optional Get NV |Device SHORT ASCII Text, Max. 50 Characters, 
Configuration STRING Manufacturer Specified. Optional 
additional information about the 
device configuration. 


13 |Conditional Get V_ |Exception Detail} STRUCT of: |A Structure of three Structures 
based on Alarm containing a bit mapped 
Exception Status representation of the alarm detail 
Bit 7 

Exception Detail 
Size Number of Common Detail Bytes 
Detail See “Semantics” section 


Detail n BYTE See “Semantics” section 


Device STRUCT of: 
Exception Detail 


Size Number of Device Detail Bytes 
Conditional Detail ARRAY of: |See Device Profile 

based on Size | 

Conditional Detail n BYTE See Device Profile 

based on Size 

Manufacturer 

Exception Detail 

Size USINT Number of Manufacturer Detail 


Conditional Detail ARRAY of: |Manufacturer Specified 
based on Size 
Conditional Detail n BYTE Manufacturer Specified 


based on Size 
14 |Conditional 
based on 
Exception Status 
Bit 7 


STRUCT of: |A Structure of three Structures 
containing a bit mapped repre- 
sentation of the warning detail 


Get V_ {Exception Detail 


Exception Detail 
Number of Common Detail Bytes 
See “Semantics” section 


BYTE See “Semantics” section 


Device STRUCT of: 
Exception Detail 


Number of Device Detail Bytes 

Conditional See Device Profile 

based on Size 

Conditional See Device Profile 

based on Size 

Exception Detail 

Number of Manufacturer Detail 
Bytes 

Conditional Manufacturer Specified 

based on Size 

Conditional Manufacturer Specified 

based on Size 
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Attr Need in Access | NV Name Data Type Description of Attribute 
ID | implementation | Rule 


15__ [Required Alarm Enable BOOL See “Semantics” section 


16 |Required | Set | 
DATE_AND |The value of the device’s internal 
_TIME realtime clock. 
See “Semantics” section 


Set 
17 |Optional (ea a i 


Required | 
Required | 
18 |Optional Get | NV [Clock Power USINT DAter be che Wehaiorot he 
Cycle Behavior device’s internal realtime clock (the 

Time attribute) during a power 
cycle 
0 = [default] clock always resets 
during power cycle 
1 = clock value is stored in non- 
volatile memory at power down 
2 = clock is battery-backed and 
runs without device power. 
3-255 = Reserved 


19 Optional Get Last DATE The date on which the device was 
Maintenance last serviced. 
Date 

20 |Optional Get Next Scheduled |DATE The date on which it is 
Maintenance recommended that the device next 
Date be serviced. 

21 Optional Get Scheduled INT See “Semantics” section 
Maintenance 
Expiration Timer 


22 Conditional - Set Scheduled BOOL See “Semantics” section 
Required if Maintenance 
Calibration Expiration 
Expiration is Warning Enable 
supported 
23 |Optional Get | NV |Run Hours UDINT An indication of the number of 
hours that the device has had power 
applied. It has a resolution of 1 
hour. This value shall be maintained 
in nonvolatile memory. 


97-98 |Reserved by CIP for Future Use 


99 |Conditional ** Get NV |Subclass UINT Identifies a subset of additional 
instance attributes, services and 
behaviors. 


* The nonvolatile behavior of the Time attribute is conditional on the value of the Clock Power 
Cycle Behavior attribute. 


** Tf the value of Subclass is 00 which identifies "no subclass", then this attribute is OPTIONAL in 
implementation, otherwise, this attribute is REQUIRED. 
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Subclasses 


Each instance level subclass defines a unique meaning for an overlapping range of instance 
attribute IDs and/or instance service IDs. The range for subclass definitions begins at ID 96 
and numbers downward for attributes, and ID 63), and numbers downward for services. The 
subclass for a given instance is identified by the value of its Subclass instance attribute. The 
subclasses for this object are specified at the end of this object specification section. 


Semantics: 

Device Type 

The Device Type attribute, identifies the Specific Device Model to which the device is modeled 
within the Hierarchy of Semiconductor Equipment Devices. The value of this string is specified 
in the SEMI standard suite referenced in the introduction section of this object definition and is 
represented for reference in the applicable device profile where used. 

Manufacturer’s Name 

The Manufacturer’s Name attribute, identifies the manufacturer of the device. It is the 
responsibility of the manufacturer to insure that this ASCH coded text string is sufficiently long 
to insure uniqueness among manufacturers. 

The Device Manufacturer attribute is not guaranteed, by specification, to be unique. Therefore, 
it is not a substitute for the corresponding attribute of the Identity Object and should not be 
used for identification purposes. 


Software Revision Level 


This is an ASCH coded text string representing the revision of the software corresponding to 
the specific device identified by the Identity object and the S-Device Supervisor object. 


Hardware Revision Level 

This is an ASCH coded text string representing the revision of the hardware which is identified 
by the Identity object and the S-Device Supervisor object. The manufacturer of the device 
must control this revision such that modifications to the device hardware may be tracked. 
Manufacturer’s Serial Number 

This attribute is a string representation of the vendor’s serial number of the device, formatted to 
fit most manufacturing tracking systems. This is not the same as the Identity Object’s serial 
number which is used to uniquely identify the device in the network environment. 


Device Status 


This attribute represents the current state of the device. Its value changes as the state of the 
device changes. The following values are defined: 
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Attribute Value State 
0 Undefined 
1 Self Testing 
2 Idle 
3 Self-Test Exception 
4 Executing 
5 Abort 
6 Critical Fault 
7-50 Reserved by CIP 
51-99 Device Specific 
100-255 Vendor Specific 


Exception Status 


A single byte attribute whose value indicates that the status of the alarms and warnings for the 
device. This indication may be provided in one of two methods: Basic or Expanded. 


For the Basic Method, bit seven of the Exception Status attribute is set to zero; all exceptions 
are reported exclusively through communication of this Exception Status attribute. The format 
of bits zero through six in this mode is device specific; the format may be further specified in 
an appropriate device profile specification; if it is not specified, then the format of bits zero 
through six is equivalent to that specified for the expanded method. 


For the Expanded Method, bit seven of Exception Status attribute is set to one; exceptions are 
reported through the communication of this Exception Status attribute, formatted as specified in 
the table below. In addition, the Exception Detail attributes are supported. The Exception 
Status bits are determined by a logical “OR” of the related Exception Detail bits, as indicated. 


Exception Status Bit Map, Bit 7 set to 0 | Exception Status Bit Map, Bit 7 set to 1 


ALARM/device-common* 

ALARM /device-specific 

Device Specific definition ALARM/manufacturer-specific 
(See Device Profile) reserved -- set to 0 

WARNING /device-common* 

WARNING /device-specific 

WARNING/manufacturer-specific 


0 == Basic Method 1 == Expanded Method 


* The alarm or warning is not specific to the device type or 
device type manufacturer. 


NY DA!) Ny BRB] WL NM] Rl] oO 


Exception Detail Alarm and Exception Detail Warning 
The formats of these two attributes are identical. Therefore, they are described together here: 


Attributes that relate the detailed status of the alarms or warnings associated with the device. 
Each attribute is a structure containing three members; these three members respectively relate 
the detailed status of exceptions that are common (i.e., not device-specific), device-specific but 
not manufacturer-specific, and manufacturer-specific. The common detail is defined below. 
The device-specific detail is defined in the appropriate Device Profile. The manufacturer- 
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specific detail is defined by the manufacturer. A SIZE value of zero indicates that no detail is 
defined for the associated exception detail structure. 


Each of the three structure members is defined as a structure containing an ordered list (i.e., 
array) of bytes of length SIZE, and an unsigned integer whose value is SIZE. Each of the bytes 
in each array has a specific mapping. This mapping is formatted as 8 bits representing 8 
independent conditions, whereas a value of | indicates that the condition is set (or present), and 
a value of 0 indicates that the condition is cleared (or not present). Note that if a device does 
not support an exception detail, the corresponding bit is never set. The bitmaps for alarms and 
warnings in the corresponding attributes are structured in parallel so that a condition may have 
either alarm or warning set depending on severity. If a condition inherently cannot be both 
alarm and warning, then the parallel bit position corresponding to the other state will remain 
"0." 


The existence of an exception detail variable structure is dependent on the value of the 
Exception Status Attribute; the existence of an exception detail variable structure is only 
required if bit seven of the Exception Status attribute is set to 1 (indicating Expanded method 
reporting) and the bit (among bits zero through six) of the Exception Status attribute 
corresponding to the particular exception type is also set to 1. 


Common Exception Detail 


This structure relates exception conditions (i.e., alarms or warnings) which are common to all 
devices within the Hierarchy of Semiconductor Equipment Devices. The Detail element of the 
structure is an ordered list (1.e., array) of bytes of length [SIZE] which is the value of the 
structure element Size. For each byte in the Detail field, all bits which are not identified are 
reserved for future standardization. 


The first byte in this attribute is CommonExceptionDetail[0]. Additional exception details, if 
provided, are named CommonExceptionDetail[1], ... CommonExceptionDetail[SIZE]. The 
specific exception associated with each of the bitmaps is given in the table below. The SIZE 
for this revision is two (2). The criteria details for each exception condition are outside the 
scope of this document. 


Common Exception Detail Attribute Values 


Common 
Exception 
Detail [0]* 


Common 
Exception 
Detail [1]* 


Internal diagnostic exception 


power supply overcurrent 


Microprocessor exception 


reserved power supply 


EPROM exception power supply output voltage 
EEPROM exception : 

power supply input voltage 
ReMescepiion scheduled maintenance due 
Reserved by CIP 


notify manufacturer 
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Common Common 
Exception Exception 
Detail [0]* Detail [1]* 


Internal real-time exception : 
reset exception 


Reserved by CIP reserved by CIP 


* Note that if a device does not support an exception detail, the corresponding bit is never set 
Device Exception Detail 


This structure, similar in form to Common Exception Detail, relates exception conditions 
which are specific to individual devices on the network and are defined in their respective 
device profiles. The Detail element of the structure is an ordered list (i.e., array) of bytes of 
length [SIZE] which is the value of the structure element size. For a detailed description of this 
attribute, consult the appropriate specific device profile. 


Manufacturer Exception Detail 


This structure, similar in form to Common Exception Detail, relates exception conditions 
which are specific to the manufacturers of individual devices on the network and are defined by 
them in their product documentation. The Detail element of the structure is an ordered list (i.e., 
array) of bytes of length [SIZE] which is the value of the structure element Size. For a detailed 
description of this attribute, consult the appropriate specific device manufacturer 
documentation. 


Exception Detail Format Summary 


Data Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
Component 
Common 0 
Exception 
Detail Size 


Common Reserved | Real-time Non- Micro- | Diagnostic 
Exception Volatile processor 
Detail 0 Memory 


Common Reserved Reset i PS Input | PS Output | Reserved | PS Over 
Exception Exception int. Current 
Detail 1 
re a net 


Exception 
Detail Size 


Device 
Exception 
Detail 0 


Device 
Exception 
Detail n 
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Data Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
Component 


Manufacturer x x xX x x x x x 
Exception 
Detail Size 


Manufacturer 
Exception 
Detail 0 


Manufacturer 
Exception 
Detail n 


Alarm Enable and Warning Enable 


These Boolean attributes are used to enable (1) or disable (0) the S-Device Supervisor object’s 
process of setting Exception bits. When disabled, corresponding bits are never set; and, if they 
were set, disabling clears them. Also, alarm and warning states are not retained; when enabled, 
bits will be set only if the corresponding condition is true. 


The default state for these Enable attributes is enabled (1). 
Time 


This optional attribute represents the value of the time and date as maintained by the device’s 
realtime clock with a resolution of one millisecond. 


The default value for the Time attribute is zero (0), corresponding to 12:00AM, January 1, 
1972, as specified by Appendix C. 


Scheduled Maintenance Expiration Timer 


This attribute, with a resolution of one hour, is used to cause a warning which indicates that a 
device calibration is due. A S-Device Supervisor timer decrements this attribute once per hour 
while power is applied. When the attribute is no longer positive and the Scheduled 
Maintenance Expiration Warning Enable attribute is set to enabled, a Scheduled Maintenance 
Expiration Warning condition is generated. This causes the Scheduled Maintenance Due 
Warning bit to be set. 


The attribute will not wrap; when the attribute reaches its most negative value, it no longer 
decrements. The attribute will continue to decrement irrespective of the state of the Scheduled 
Maintenance Expiration Warning Enable attribute. The value shall be maintained in 
nonvolatile memory. 


Scheduled Maintenance Expiration Warning Enable 

This Boolean attribute is used to enable (1) or disable (0) the S-Device Supervisor object’s 
process of setting the Scheduled Maintenance Due Exception bit. When disabled, the 
corresponding bit is never set; and, if it was set, disabling clears it. When enabled, the bit will 


be set only if the corresponding condition is true. 


The default state for this Enable attribute is enabled (1). 
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S-Device Supervisor Common Services 


Service Need in Implementation Service Name Description of Service 


Code 
OEhex Conditional | Required | Get_Attributes Single | Returns the contents of the 
specified attribute. 


10hex | n/a_—_—‘|- Required | Set_Attributes Single | Modifies an attribute value. 


O5hex n/a Required Reset Resets the device to the 
Self-Testing state. 


06hex n/a Required Start Starts the device execution 
by moving the device to 
the Executing state. 
Equivalent to SEMI S/A 
Network Execute Service 
Idle state 


S-Device Supervisor Object Specific Services 


Service Need in Implementation Service Name Description of Service 


Code 

4Bhex n/a Required Abort Moves the device to the 
Abort state 

4Chex n/a Required Recover Moves the device out of 
the Abort state 


4Ehex n/a Required | Perform Diagnostics | Causes the device to 
perform a set of diagnostic 
routines 


DS Object Service Parameter ieee 


Parameter |Description of Service =| of Service 


TestID USINT Type and possibly detail of diagnostic test to be 
performed 


Abort — Used to transition the device application objects to the aborted state. This service 
request may be (and generally will be) originated internally, from application objects. 


Recover — Used to transition the device application objects, out of the abort state, to the idle 
state. This service request may be originated internally, from application objects. 


Perform_Diagnostics — Used to instruct the S-Device Supervisor object to perform a 
diagnostic test. A diagnostic test is either of type common or device-dependent. Common 
diagnostic tests could include: RAM, EPROM, non-volatile memory, and communications. 
The structure of common type diagnostic tests are implementation-specific. All detail of 
device-dependent diagnostics is outside the scope of this document. 


TestID Parameter 
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The following values are defined for the TestID parameter for the Perform_Diagnostics Service 


Request: 
Attribute Value State 
0 Standard 
1-63 Reserved 
64-127 Device Specific (defined in Device Profile) 
128-255 Manufacturer Specific (defined by manufacturer) 


Type “Standard” is specified if there is only one type of diagnostic defined or if there are more 
than one including a type standard. Additional diagnostic types may be defined in the device 
profile or by the manufacturer. 


5-35.5. S-Device Supervisor Behavior 


5-35.5.1. S-Device Supervisor Object States 
Figure 5-35.1 DS Object Instance Behavior 


Power Applied, or 
Reset Request from any state except CRITICAL FAULT, or 
Perform Diagnostics Request from any state except CRITICAL FAULT or ABORT 


| 


Self- Self-Test Failed , Self-Test 
Testing Recover Request or Exception 
Exception Condition 
Cleared 
Self-Test 
Passed Abort Request 
v 
Idle Abort Request > Abort 
qhecover Request 
Critical 
Stop Request or Start Request or Fault 
I/O ConnectionTimgout Receipt of First 
or I/O Connection Valid I/O Data 
Deleted 
: Abort Request 
Executin 4 
CUNO Critical Fault 
from any state 


Table 5-35.2 DS Instance Behavior State Description 
State Description 


EXECUTING Device is executing, e.g., it is performing its device specific function. A detailed 
description of this state is outside the scope of this document. This state may be further 
specified in an appropriate device profile specification. 


SELF TESTING Object instance exists and has been initialized; all attributes have appropriate initial 
values (as indicated herein and in applicable device profile specification). Exception 
Status bits have been reset. Device is performing device-specific and device type 
specific test to determine if it is qualified to execute its application process. 


SELF TEST Object has detected an exception condition during self-testing. The details of the 
EXCEPTION exception are stored in the appropriate attribute values of the S-Device Supervisor 
object. 
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IDLE Object and device have been initialized and successfully completed self-testing. 
Further, the device is not executing the operational components of its device specific 
functions. 

ABORT Object instance is in an aborted state; a detailed description of this state is outside the 
scope of this specification. 

CRITICAL FAULT The object (and device) are in a fault state from which there is no recovery. object 


services cannot be processed. The conditions required for exit from a critical fault is 
outside the scope of this specification. 


The S-Device Supervisor Status attribute value indicates the state of the S-Device Supervisor 
object. It is updated on appropriate state transitions within the S-Device Supervisor object. 
Attribute values | through 6 represent valid states. A value of zero indicates that the S-Device 
Supervisor state is unknown; conditions under which a zero value may occur are outside the 
scope of this document. 


5-35.5.2. S-Device Supervisor State Event Matrix 


Table 5-35.3 State Event Matrix for S-Device Supervisor Object 
Event State 


Self-Testing Self-Test Executing Abort Critical Fault 
Exception (Recoverable 


Power Default Entry Transition to 
Applied Point: Device SELF-TESTING 
performs its Self- 
Test Application 
Process 


Self-Test Not Transition to Not Not Not Not 
Passed Applicable IDLE Applicable Applicable Applicable Applicable 
ot Not Not 


Self-Test N Set appropriate Not Not 


Failed Applicable | Exception Status | Applicable Applicable Applicable Applicable 
Bits and 
Transition to 
SELF-TEST 
EXCEPTION 
Exception Not Not Set appropriate Not Not Not 
Condition Applicable Applicable Exception Status | Applicable Applicable Applicable 
Cleared Bits and 
Transition to 
SELF-TESTING 
Critical Fault} Transition to Transition to Transition to Transition to Transition to Ignore Event 


CRITICAL CRITICAL CRITICAL CRITICAL CRITICAL 


FAULT FAULT FAULT FAULT FAULT 

Reset Transition to Restart SELF- Transition to Transition to Transition to Ignore Event 
Start Request| Transition to Error OSC* Error OSC* Error AIRS* Error OSC* Ignore Event 

[emevrme | Oe | meee | eae | eee 
Stop Request| Error AIRS* Error OSC* Error OSC* Transition to Error OSC* Ignore Event 

eee ee 

Request ABORT ABORT ABORT 

Recover Error OSC* Restart SELF- Transition to Error OSC* Transition to Ignore Event 
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Event 
Perform Transition to Restart SELF- Transition to Transition to |Perform all device] Ignore Event 
Diagnostics |SELF-TESTING TESTING SELF-TESTING | SELF-TESTING | diagnostics test. 
Request 


Timeout IDLE 
Receipt of Transition to Ignore Event Ignore Event | Normal Response Ignore Event Ignore Event 
First Valid | EXECUTING 

I/O Data 


Vo Ignore Event Ignore Event Ignore Event Transition to Ignore Event Ignore Event 
Connection IDLE 
Deleted 


* Error AIRS = Error Response “Already in Requested Mode/State” (Code 0Bh.x) 
Error OSC = Error Response “Object State Conflict” (Code 0C,..) 


Any S-Device Supervisor instance service may be requested internally by the device as 
specified by the manufacturer. Generally, these requests will be generated as the result of an 
event such as the activation of a button or external contact closure. 


5-35.5.3. S-Device Supervisor and Identity Object Interface 


The following two tables describe the effects that the Identity object and the S-Device 
Supervisor object have on each other based on events. This event mapping defines the interface 
between these two objects. 


Table 5-35.4. Effect of Identity Object Event 


Identity Object Event S-Device Supervisor Object Affected Event 
Power Applied Power Applied 
Failed Tests Self-Test Failed 
Passed Tests Self-Test Passed 
Deactivated Stop Request * 
Activated Start Request * 
Major Recoverable Fault Abort Request * 
Major Unrecoverable Fault Critical Fault 
Minor Fault No effect 
Fault Corrected Exception Condition Cleared 
Reset Reset Request * 


* The S-Device Supervisor object service requests are generated by the device in response to these events. 


Table 5-35.5. Effect of S-Device Supervisor Object Event 


S-Device Supervisor Object Event Identity Object Affected Event 
Power Applied Power Applied 
Self-Test Passed Passed Tests 
Self-Test Failed Failed Tests 
Exception Condition Cleared Fault Corrected 
Critical Fault Major Unrecoverable Fault 
Reset Request Deactivated 
Start Request Activated 
Stop Request Deactivated 
Abort Request Major Recoverable Fault 
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S-Device Supervisor Object Event Identity Object Affected Event 


Fault Corrected 
No effect. * 


* The request to perform diagnostics has no effect on the Identity Object. However, the results of the tests may. 


Recover Request 


Perform Diagnostics Request 


5-35.5.4. S-Device Supervisor and Application Object Interface 


When processing Stop, Start, Reset, Abort, Recover and Perform Diagnostics service requests, 
the S-Device Supervisor object coordinates all Application Objects within the device, as 
appropriate, in order that they will exhibit behavior consistent with the S-Device Supervisor 
object instance state. 


This object interfacing is best described in the SEMI standard suite as referenced in the 
introduction section of the object definition. 
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5-36. 


5-36.1. 


5-36.2. 


Release 1.0 


S-ANALOG SENSOR OBJECT 
Class Code: 31hex 


The S-Analog Sensor Object models the acquisition of a reading from a physical sensor in a 
device. Associated with an analog sensor is a reading that has been acquired and corrected 
with an offset and a gain coefficient, optionally, settable in the object. Additional correction 
algorithms may be specified by other objects identified in the device profile or as extensions 
specified by the manufacturer. 


This object is a member of the Hierarchy of Semiconductor Equipment Devices. As such, its 
behavior is managed by the S-Device Supervisor Object. See Section 5-35. 


Class Attributes 


Attr ID Need in Access | Name Data Type | Description of | Semantics of Value 
Implementation | Rule Attribute 


1 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 
94-96 | Defined by Subclasses 
97-98 | Reserved by CIP for Future Use 


99 Conditional * Get | Subclass UINT Identifies a subset 0 = No subclass 
of additional class | 1 = Instance Selector 
attributes, 2 - 65535 = Reserved 
services and by CIP 
behaviors. 


* Tf the value of Subclass is 00, which identifies "no subclass", then this attribute is 
OPTIONAL in implementation, otherwise, this attribute is REQUIRED. 


Subclasses 


Each class level subclass defines a unique meaning for an overlapping range of class attribute 
IDs and/or class service IDs. The range for subclass definitions begins at ID 96 and numbers 
downward for attributes, and ID 63)... and numbers downward for services. The subclass for a 
given class is identified by the value of its Subclass class attribute. The subclasses for this 
object are specified at the end of this object specification section. 


Instance Attributes 


Certain minimal implementations may support any optional “Set” attributes as “Get Only” and 
still be compliant with this object specification. All required attributes must be supported as 
specified. 
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10 


11 


12 


Need in Access | NV Name Data Type Description of |Semantics of Values 
Implementation | Rule Attribute 
Optional Get NV_ {Number of USINT Number of 
Attributes attributes 
supported 
Optional Get NV_ [Attribute List |ARRAY OF List of attributes 
USINT supported by this 
object instance 
Optional See NV_ |Data Type USINT Determines the see Semantics 
Semanti Data Type of section 
cs Value and all ({default] = INT 
related attributes 
as specified in this 
table. 
Optional See NV_ {Data Units ENGUNITS Determines the see Semantics 
Semanti Units context of — {section 
cs Value and all [default] = Counts 
related attributes. 
Required Get V_ |Reading Valid |BOOL Indicates that the |0 = invalid 
Value attribute 1 = valid 
contains a valid __|(invalid: e.g., not 
value. warmed up yet) 
Required Get V_ {Value INT or specified }Analog input The corrected, 
by Data Type if |value converted, calibrated 
supported final value of the 
sensor. 
see Semantics 
section 
Required Get V_ {Status Alarm and see Semantics 
Warning State of |section 
this object 
instance 
Optional Set NV_ {Alarm Enable Enables the setting |0 = disable [default] 
of the Alarm 1 =enable 
Status Bits 
Optional Set NV_ |Warning Enables the setting |0 = disable [default] 
Enable of the Warning 1 =enable 
Status Bits 
Optional Get NV_ |Full Scale The Value of Full |The value of 
Scale for the attribute Value 
sensor. corresponding to the 
Full Scale calibrated 
measurement of the 
sensor. 
({default] = maximum 
allowable value for 
the Data Type 
Optional Get NV_ |Offset-A Data Determines the see Semantics 
Data Type of section 
attribute Offset-A [default] = INT 
Optional Set NV_ |Offset-A INT or specified }An amount added |see Semantics 
by Offset-A Data |prior to Gain to section 
Type if supported |derive Value 0 = [default] 
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Need in Access | NV Name Data Type Description of |Semantics of Values 
Implementation | Rule Attribute 


Determines the 
Data Type of 
attribute Gain 


Release 1.0 


Attr 
ID 


13 |Required if 
Attribute “Gain” 


is other than 
REAL 


14 |Optional Set NV_ {Gain REAL or 
specified by 
Gain Data Type 
if supported 


15 |Required if Get NV_ [Unity Gain REAL or 
Reference 
Set NV 


Attribute “Gain” specified by 
is other than Gain Data Type 
REAL if supported 
: al a — 
17. |Optional Set NV_ [Alarm Trip 
Point High 
18  |Optional Set NV_ [Alarm Trip 
Point Low 
. 7 


Hysteresis 
| | 


. 
Ff 


INT or specified 


INT or specified 
by Data Type if 
supported 


INT or specified 
by Data Type if 
supported 


INT or specified 
by Data Type if 
supported 


Alarm Settling 
Time 


Warning Trip 
Point High 


INT or specified 
by Data Type if 
supported 


Warning Trip 
Point Low 


INT or specified 
by Data Type if 
supported 


Open DeviceNet Vendor Assoc. & ControlNet International 


Get NV_ |Gain Data USINT 
Type 


Chapter 5: Object Library 


see Semantics 
section 


[default] = REAL 


see Semantics 
section 


1.0 = [default] 


An amount scaled 
to derive Value 


Specifies the value}Used for normalizing 
of the Gain the Gain attribute. 


attribute [default] = 1.0 


equivalent to a 

gain of 1.0 e.g., for an UINT 
type Gain, a Unity 

Gain Reference may 

be 10000, allowing a 

gain of 0.0001 to 

6.5535. 


see Semantics 
section 


0 = [default] 


see Semantics 
section 

[default] = 
Maximum value for 
its data type. 

see Semantics 
section 

(default] = Minimum 
value for its data 
type. 

see Semantics 
section 

[default] = 0 


An amount added 
to derive Value 


Determines the 
Value above 
which an Alarm 
Condition will 
occur 

Determines the 
Value below 
which an Alarm 
Condition will 
occur 

Determines the 
amount by which 
the Value must 
recover to clear an 
Alarm Condition 
Determines the Time in milliseconds 
time that the see Semantics 

Value must exceed |section 

the Trip Point [default] = 0 

before the 
exception 
condition is 
generated. 
Determines the 
Value above 
which a Warning 
Condition will 
occur 
Determines the 
Value below 
which a Warning 
Condition will 
occur 


see Semantics 
section 

[default] = 
Maximum value for 
its data type. 

see Semantics 
section 

(default] = Minimum 
value for its data 
type. 
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NV Name Data Type Description of |Semantics of Values 
Attribute 
N 


Optional Set V_ | Warning INT or specified |Determines the see Semantics 
Hysteresis by Data Type if |amount by which |section 
supported the Value must ({default] = 0 
recover to clear a 
Warning 
Condition 
Warning Determines the Time in milliseconds 
Settling Time time that the see Semantics 
Value must exceed |section 
the Trip Point [default] = 0 
before the 
exception 
condition is 
generated. 


Safe State Specifies the see Semantics 
behavior for the {section 
Value for states [default] = 0 
other than Execute 


Safe Value INT or specified |The Value to be |see Semantics 
by Data Type if |used for Safe State }section 
= Safe Value [default] = 0 


Autozero Enables the see Semantics 


Attr Need in Access 
ID_ | Implementation] Rule 


N 
Ww 


N 
& 


N 
| 


Optional Set NV 


Z 
x 


Z Z Z 


25  |Optional Set 


N 
an 


Optional Set 


Optional Set 


Enable Autozero section 
0 = disable [default] 
1 = enable 
28 |Optional Get Autozero Indicates the see Semantics 
Status status of the section 
automatic nulling |[default] = 0 
29  |Optional Set Autorange Enables the see Semantics 
Enable automatic range _|section 
switching 0 = disable [default] 
1 =enable 
30 {Optional Get Range Indicates the see Semantics 
Multiplier current range section 
multiplier [default] = 1.0 
31 {Optional Set NV_ |Averaging Specifies the time |Time in Milliseconds 
Time over which analog |of a moving-window 
samples are average. 
averaged. 0 = disable 


averaging [default] 
Values less than the 
sample rate of the 
device also disable 
averaging. 
Overrange INT or specified |Specifies the The value above 
by Data Type if |highest valid which attribute 
supported Value Reading Valid is set 
to invalid. 
({default] = maximum 
allowable value for 
the Data Type 


32 |Optional Get NV 
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Attr 
ID 


33 |Optional Get NV_ |Underrange INT or specified 
by Data Type if 
supported 

34 |Optional Set NV_ |Produce INT or specified 

Trigger Delta |by Data Type if 

35 |Conditional * Set NV_ |Gas 

Calibration 

Object 

Instance 


supported and/or 
36 {Optional Set NV_ |Produce 
Trigger Delta 
Type 


Produce Trigger 
79-96 |Defined by Subclasses below 
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Need in Access | NV Name Data Type Description of |Semantics of Values 
Implementation | Rule Attribute 


The value below 
which attribute 
Reading Valid is set 
to invalid. 

({default] = minimum 
allowable value for 
the Data Type 

0 = Disabled 
[default] 

See Semantics 
section 


Specifies the 
lowest valid Value 


The amount by 
which Value must 
change before a 
Change of State 
Production is 
triggered 
Indicates which 
Gas Calibration 
object instance is 
active for this 
object 

Specifies the Type 
for Produce 
Trigger Delta 


0 = Disabled 
[default] 

See Semantics 
section 


0 = [default] 
See Semantics 
section 


97-98 |Reserved by CIP for Future Use 


0 =No subclass 

1 = Flow 
Diagnostics 

2 = Heat Transfer 
Vacuum Gauge 

3 = Capacitance 
Manometer 

4 = Cold Cathode 
Ion Gauge 

5 = Hot Cathode Ion 
Gauge 
6-65535=Reserved 
by CIP 


99 Conditional ** 


Identifies a subset 
of additional 
instance attributes, 
services and 
behaviors. 


* See Semantics section. 
** Tf the value of Subclass is 00, then this attribute is OPTIONAL in implementation, 
otherwise, this attribute is REQUIRED. 


Subclasses 


Each instance level subclass defines a unique meaning for an overlapping range of instance 
attribute IDs and/or instance service IDs. The range for subclass definitions begins at ID 96 
and numbers downward for attributes, and ID 63), and numbers downward for services. The 
subclass for a given instance is identified by the value of its Subclass instance attribute. The 
subclasses for this object are specified at the end of this object specification section. 


Semantics: 


Data Type 


All Data Type attributes, including Data Type, Offset-A Data Type and Gain Data Type, use 
the enumerated values specified in Appendix C-6.1. 
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The Data Type attribute is settable only in the /dle State and only if no attribute belonging to 
the object instance is the endpoint of an I/O connection in the Established State. 


The Data Type attribute may change automatically based upon established I/O connections. See 
Behavior section for more information on this mechanism. 


Data Units 


Specifies the context of Value and related attributes (such as, offset and trip points) for this 
object instance. See Appendix K for a list of values. A request to set attribute to an unsupported 
value will return an error response. 


The Data Units attribute is settable only in the /dle State. 
Value, Offset (A and B) and Gain 


An S-Analog Sensor object instance derives a reading from a physical analog sensor. The 
reading is converted to the data type and units specified for the Value attribute. The Offset-A, 
Offset-B and Gain attributes are applied to the sensor reading as specified by the following 
formula: 


Value = Gain e ( Sensor Reading + Offset-A ) + Offset-B 


Typically, the Offset-A or Offset-B attributes are modified by the Zero-Adjust service and the 
Gain attribute is modified by the Gain_Adjust services; particularly, when the device utilizes a 
non-linear conversion algorithm. However, support of these services is not required. See 
Behavior section. 


Status 


A bit mapped byte which indicates the Alarm and Warning Exception status of the object 
instance. The following definition applies: 


Bit Definition 

0 High Alarm Exception: 0 = cleared; 1 = set 

1 Low Alarm Exception: 0 = cleared; 1 = set 

2 High Warning Exception: 0 = cleared; 1 = set 
3 Low Warning Exception: 0 = cleared; 1 = set 
4 Reserved 

> Reserved 

6 Reserved 

7 Reserved 


Trip Points, Hysteresis and Settling Time 


Trip Point High is the level above which the Value attribute will cause an Alarm or Warning 
exception condition. 


Trip Point Low is the level below which the Value attribute will cause an Alarm or Warning 
exception condition. 
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A Hysteresis value specifies the amount by which the Value attribute must transition in order to 
clear an Alarm or Warning condition. For example: A Trip Point High value of 100 and a 
hysteresis value of 2 will result in an exception condition being set when the Value is above 
100 and cleared when the Value drops below 98. Similarly, A Trip Point Low value of 100 and 
a hysteresis value of 2 will result in an exception condition being set when the Value is below 
100 and cleared when the Value increases above 102. 


The Settling Time determines the amount of time that the Value attribute must exceed the Trip 
Point before the exception condition is generated. The Settling Time also applies to the 
clearing of the condition. 


Safe State 


This attribute specifies what value will be held in Value for states other than Executing. See 
the S-Device Supervisor object definition in Section 5-35. for a description of object states. 
The purpose of this mechanism is to allow other devices, that may be using this Value, to 
transition to, or remain in, a safe state in the event of this device transitioning to a FAULT, 
IDLE, or ABORT state. The following values are defined: 


Attribute Value State 

0 Zero 
1 Full Scale 
2 Hold Last Value 
3 Use Safe Value 

4-50 Reserved 

51-99 Device Specific 

100-255 Vendor Specific 
Safe Value 


For Safe State set to Use Safe Value, this attribute holds the value to which the Value attribute 
will be set for object instance states other than Executing. 


Autozero Enable and Autozero Status 

When the autozero is enabled, the device will automatically invoke a Zero Adjust service 
request (no parameter) contingent upon a set of conditions specified by the manufacturer. 
These conditions may be determined by the value of an attribute (e.g., setpoint) or some other 


mechanism defined by the manufacturer. See Zero_Adyjust service. 


While the device is in the process of nulling due to an Autozero event, the value of Autozero 
Status is one (1). When the device is not in the process of nulling, this value is zero (0). 


Autorange Enable and Range Multiplier 
When the autorange is enabled, the device will automatically switch full-scale range based on a 


set of conditions specified by the manufacturer. The Range Multiplier indicates the range 
scale. 
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An example of how Autorange may work is: when the Value is less than 9% with a Range 
Multiplier of 1.0, the Range Multiplier switches to 10.0 (the Value then reads 90% of the 10X 
range). When the Value then reaches 100% with a Range Multiplier of 10.0, the Range 
Multiplier returns to 1.0 (the Value then reads 10% of the 1X range). 


Produce Trigger Delta 


This attribute is used in conjunction with the "Change of State" production trigger type. Upon 
transition of the associated connection object instance (any Change of State connection 
pointing to the S-Analog Sensor object Value attribute) to the established state, a production is 
immediately triggered and this reported Value is stored internally for the determination of the 
next production trigger. When the Value changes by an amount of at least the Produce Trigger 
Delta (i.e., the Value as compared to the internally stored previously produced Value), a new 
production is triggered, and this reported Value becomes the new internally stored Value for 
the determination of the next production trigger. The interpretation of this attribute is absolute 
value unless otherwise specified by the Produce Trigger Delta Type attribute. 


Gas Calibration Object Instance 


This attribute is used to select an instance of the S-Gas Calibration object. The selected S-Gas 
Calibration object instance provides the data with which an S-Analog Sensor object instance 
enacts the appropriate calibration algorithm for a given gas type. 


A Set_Attribute_ Single request, specifying a value not supported, will return an “invalid 
attribute value” error response. A list of acceptable values for this attribute is derived from a 
class level service request to the S-Gas Calibration object. 


Conditionally Required: If a device profile specifies an S-Gas Calibration object relationship 
for an S-Analog Sensor object instance, then this attribute is required. See the S-Gas 
Calibration object definition for more information. 


Produce Trigger Delta Type 


The Produce Trigger Delta Type attribute specifies the interpretation of the Produce Trigger 
Delta attribute. The following values are defined: 


Produce Trigger Delta Type Produce Trigger Delta Type | Produce Trigger Delta Data Type 


Attribute Value 
0 [default] As Specified by Data Type 
1 UINT 
2-255 Reserved by CIP for Future Use 


Due to the logarithmic, or other non-linear nature of some analog measurements, the data units 
of the Produce Trigger Delta attribute may be set to a Percent Produce Trigger Delta. This 
also causes the Data Type of Produce Trigger Delta to be type UINT with a resolution of 
0.1%. 


For example, if the last COS-produced reading was 5E-5, the Produce Delta Trigger Type was 


set to | (Percent), and the Produce Trigger Delta = 200 (which equates to a delta of 20%), then 
the next reading will be produced at 4E-5 or 6E-5. 
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5-36.3. Common Services 


The S-Analog Sensor Object provides the following Common Services: 


Service Need in Implementation Service Name Description of Service 
Code 


OEhex Get_Attribute Single | Returns the contents of the specified 
attribute. 


Olhex n/a Set_Attribute Single | Modifies an attribute value. 


*The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 
5-36.4.1. Object—Specific Services 
The S-Analog Sensor Object provides the following Object-Specific Services: 


Service Need in Implementation Service Name Description of Service 
Code 


4Bn iS n/a Causes the device to modify attribute Offset-A 
and/or Offset-B such that attribute Value equals 
the Target Value sent with the request. 

ACh, _ Causes the device to modify attribute Gain, such 
that attribute Value, equals the Target Value sent 
with the request. 


The Zero_Adjust and Gain_Adjust services are used to cause the S-Analog Sensor Object 
device to modify its Offset-A and/or Offset-B and Gain attribute values based upon 
manufacturer specific algorithms. The target value specified in the service request represents 
the actual parametric measurement that the physical sensor should be reporting at the time of 
the request. 


There are no state transitions associated with the invocation of these services. It is, therefore, 
incumbent upon the user to establish the device into the desired configuration prior to, and 
during, the execution of these services. This will generally involve exposing the sensor to a 
known environment and treating the values read during execution of the services accordingly. 


A success service response indicates that the service was accepted and the application process 
started. 


Zero Adjust Request Service Data Field Parameters 


Parameter Data Type Semantics of Values 


Target Optional Specified by the | The target value The value to which the Value 
Value value of for the zero attribute will be set. If not specified, 
attribute Data calibration the default value of zero is used. 


Type 


Gain Adjust Request Service Data Field Parameters 


Parameter Data Type Semantics of Values 


Target Required Specified by The target value The value to which the Value 
Value the value of for the gain attribute will be set. 
attribute Data calibration 


Type 
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Behavior 


The behavior of this object is managed by the S-Device Supervisor Object in Section 5-35.5. 


An S-Analog Sensor object instance acquires a reading from a physical sensor, as identified by 
the application of the object, and applies an algorithm to modify the reading into the 
appropriate Date Type and Data Units. Optionally, additional corrective algorithms are applied 
to further correct for various calibration effects. These additional algorithms are specified in 
other objects, as identified in the device profile, or as extensions, specified by the 
manufacturer. 


All Full Scale, Trip Point, Overrange and Underrange calculations, as specified above, utilize 
the Value attribute. 


Data Type 


If the implementation of this object specifies more than one valid Data Type value, in the 
device profile or by vendor, then the following behavior with respect to Data Type applies: 
The Data Type value will be set automatically based upon the first valid I/O connection 
established by the device. If, however, a device is specified by a vendor to support only one 
Data Type, this behavior is not supported. 


If no established I/O connections exist, which include an attribute from this object, then the 
Data Type attribute is settable provided that the object is in the /dle State. The following 
example demonstrates this behavior: 


A device profile specifies an instance of the S-Analog Sensor object as well as two static 
Assembly object instances, both with data attribute components mapped to this object instance. 
Assembly object instance ID 1 specifies INT data types and Assembly object instance ID 2 
specifies REAL data types. 


After the device is On-Line, it is configured with an I/O connection to Assembly instance ID 2. 
When the connection transitions to the Established State, this object instance attribute Data 
Type is automatically set with the value for REAL before any data is communicated to, or 
from, the object instance. Any subsequent attempt to connect to Assembly instance ID 1 would 
then be rejected and result in an INVALID ATTRIBUTE VALUE error with the additional 
error code indicating the ID of the offending attribute, which in this case would be the 
connection path. 


S-Analog Sensor Object Class Subclass 01 (Instance Selector) 


The following is a class-level subclass extension to the S-Analog Sensor Object. It provides a 
single port mechanism for flowing data from the active S-Analog Sensor Instance and allowing 
that the Active Instance ID may change. The intended application is for Gauge Controllers 
where more than one gauge is connected, but only one gauge is considered the "active" gauge. 
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CLASS ATTRIBUTES 


The following Class Attributes are specified for this object subclass. 


Attr ID Need in Access Name Data Type Description of Attribute | Semantics 
Implementation | Rule of Values 
ID 3) if supported (Attribute ID 6) of the S- 


94 Optional Ge 
Analog Sensor Instances. 
95 Optional Get Active Identifies the object instance | Default = 
Instance that is providing the Value 1 
Number which is copied into the 
Active Value for all input 
Assemblies and the 
Alarm/Warning Exception 
Details for the S-Device 
See Behavior section. 
et 


Supervisor object. 
96 Optional G Number of USINT Identifies the number of default = 
Gauges gauge instances present in the | [gauge- 
device. specific] 


Semantics: 


Active INT or specified | Can be used by assemblies to 
Value by Data Type produce this class-level 
(Instance Attribute | attribute, instead of the Value 


NV 
t Vv 
Vv 

NV 


Active Value 


Assemblies or connections may produce this class-level attribute, instead of the Value 
(Attribute ID 6) of the active S-Analog Sensor instance. The S-Analog Sensor class-level 
attribute Active Instance Number identifies the object instance that is currently active and 
providing the Value to the Active Value class-level attribute which is, in turn, produced by the 
input assemblies that have Active Value as a member. 


Active Instance Number 

The device internally modifies this attribute, as required, to identify the S-Analog Sensor object 
instance providing the Value member which is copied into the Active Value for all Input 
Assemblies and the Alarm/Warning Exception Details for the S-Device Supervisor object. 

See Behavior for more information on the mechanism. 


Number of Gauges 


This attribute is used to determine the size of all Input Assemblies within a node. See the 
respective Device Profile for its usage within a Device Type. 


SERVICES 


There are no additions or restrictions to the Object Services for this object subclass. 
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BEHAVIOR 


The specific algorithm used to set the Active Instance Number is manufacturer specific. 
However, most will follow the basic logic that each of multiple gauges are valid (or ideally 
suited) for specific ranges of measurement. Therefore, the Active Instance Number will be 
modified based upon the Active Value in order that the best gauge, corresponding to a given S- 
Analog Sensor instance, will be active for the given measurement range. 


S-Analog Sensor Object Instance Subclass 01 (Flow Diagnostics) 


The following specification applies to a subclass of this object for application in Mass Flow 
Controller devices. 


INSTANCE ATTRIBUTES 


The following Instance Attributes are specified for this object subclass. 


Attr ID Name Data Daw type Deseriion ot Atrbte of Attribute Semantics of Values 
Implementation — 
95 | Optional NV ced ae eeweree gas flowed through the | Units are Standard CCs 
Totalizer device since this value was last] see aang section 
set to zero default = 
96  |Optional NV_|Flow Hours }|UDINT Total time device has been Secu is one hour 
powered and flowing gas since | see eg section 
this value was last set to zero _| default = 
SERVICES 


There are no additions or restrictions to the Object Services for this object subclass. 


BEHAVIOR 


Flow Totalizer and Flow Hours Process 


The factory configured out-of-box values for the Flow Totalizer and Flow Hours attributes are 
both zero. The attributes are only modifiable with set_attribute_single service requests; they 
are not altered by the Reset service, including power-cycle, of either the Identity or the S- 
Device Supervisor objects. 


The Flow Totalizer attribute is incremented, at a rate of once every cubic centimeter of gas 
flow, by the S-Analog Sensor object instance to reflect the amount of gas that has flowed 
through the device. Upon reaching its maximum value, the Flow Totalizer value is no longer 
incremented and remains at its maximum value. 


The Flow Hours attribute is incremented, at a rate of once every hour, by the S-Analog Sensor 
object instance to reflect the amount of time that gas has flowed through the device. This 
condition is determined by the Value attribute being greater than 0.5% of full scale. Upon 
reaching its maximum value, the Flow Hours value is no longer incremented and remains at its 
maximum value. 
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S-Analog Sensor Object Instance Subclass 02 (Heat Transfer Vacuum 
Gauge) 

OVERVIEW 

Following is a subclass extension to the S-Analog Sensor Object. The original usage for the 
subclass is for Heat Transfer Vacuum Gauges. The Heat Transfer Vacuum Gauge extension is 
used in conjunction with the Vacuum/Pressure Gauge Profile providing control and status 
information unique to heat transfer gauges - Convection, Pirani and Thermocouple gauge types. 
INSTANCE ATTRIBUTES 

Certain minimal implementations may support any optional ’’Set” attributes as ’Get” only and 


still be compliant with this object specification. Although no attribute is individually required, 
this object requires that one or more attributes be used. 


Implementation |_ Rule Values 
91 |Optional Set NV _ |Cable Length UINT Transducer cable length | [default = 0] 
for compensation, if Units in cm 
required see Semantics 
92 ‘| Optional Set NV_ | Sensor High Real Maximum [default = 0] 
Temp Warning compensatable Sensor | Units in °C 
Value Temperature. 
93 | Optional Get V_ | Sensor Real Sensor temperature in | see Semantics 
Temperature 2C. 
94 | Optional Get V_ {Sensor Warning |STRUCT of | Bit definitions of ({default=0] 
BYTE Sensor Warning see Semantics 
BYTE 
95 | Optional Get V_ | Sensor Alarm STRUCT of | Bit definitions of ({default=0] 
BYTE Sensor Alarms see Semantics 
BYTE 


96 |Optional Get V_ |Status Extension |BYTE Bit-mapped byte [{default=0] 
providing additional see Semantics 
status bits of an S- 
Analog Sensor instance. 


Semantics: 
Cable Length 


This attribute specifies the cable length of the transducer cable (cable between the sensor 
[filament] and its electronic). 


Sensor Temperature 


Ambient temperature of the sensor housing. This value could be used for temperature 
compensation. 


Sensor Warning 
The Sensor Warning attribute provides 16 bits for the current Sensor Warning state of the 
object. The Sensor Warning attribute also maps to the S-Device Supervisor Exception Detail 


Warning attribute. The following table provides definitions for each Sensor Warning bit. 
Reserved bits must be set to zero. 
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Data Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
Component 
Sensor Warning Ice Pees eee | Le] Reserved 
Byte 0 


Sensor Warning baa bea Reserved | Reserved | Reserved | Sensor feel ial Reserved 
Byte 1 Temperature | Warning 
Warning 


Sensor Alarm 


The Sensor Alarm attribute provides 16 bits for the current Sensor Alarm state of the object. 
The Sensor Alarm attribute also maps to the S-Device Supervisor Exception 
Detail Alarm attribute. The following table provides definitions for each Sensor Alarm 
bit. Reserved bits must be set to zero. 
Data 


Component 
Sensor Alarm | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Reserved Sensor 
Byte 0 Element 
i a Ma ise 


Sensor Alarm | Reserved | Reserved | Reserved | Reserved | Reserved Over Electronics | Reserved 
Byte 1 Temperature | Failure 
of 
Electronics 


Status Extension 


8 Bits providing the current sensor alarm state of the object. 


Reserved | Reserved | Reserved | Reserved | Reserved | Underrange | Overrange} Reading 
Exceeded | Exceeded | Invalid* 
* Note: Logical inversion of Reading Valid 


SERVICES 


There are no additions or restrictions to the Object Services for this object subclass. 


BEHAVIOR 


There are no additions or restrictions to the Object Behavior for this object subclass. 


5-36.9. S-Analog Sensor Object Instance Subclass 03 (Diaphragm Gauge) 
OVERVIEW 


Following is a subclass extension to the S-Analog Sensor Object. The original usage for the 
subclass is for Diaphragm Gauge Gauges. The Diaphragm Gauge extension is used in 
conjunction with the Vacuum/Pressure Gauge Profile providing control and status information. 


INSTANCE ATTRIBUTES 
Certain minimal implementations may support any optional ’’Set” attributes as ’Get” only and 


still be compliant with this object specification. Although no attribute is individually required, 
this object requires that one or more attributes be used. 
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Data Type _ | Description of Attribute | Semantics of Values 

Sensor REAL The temperature in degrees Celsius 

Temperature Celsius at which the [default] = vendor 
sensor has warmed up. |specific 


Need in Access | NV 
Implementation} Rule 
Vv STRUCT of |Bit definitions of [default=0] 
BYTE Sensor Warnings See Semantics 


BYTE 
Sensor Alarm |STRUCT of |Bit definitions of [default=0] 
Sensor Alarms See Semantics 


ae ae 


Semantics: 


Set 
Get 
Get 

et 


Status Bit mapped byte [default=0] 
Extension providing additional See Semantics 
status of an S-Analog 
Sensor instance. 


Sensor Warning 


The Sensor Warning attribute provides 16 bits for the current Sensor Warning state of the 
object. The Sensor Warning attribute also maps to the S-Device Supervisor Exception Detail 
Warning attribute as specified in the Pressure/Vacuum Gauge device profile. The following 
table provides definitions for each Sensor Warning bit. Reserved bits must be set to zero. 


Data Component Bit 0 
Not At 


Byte 0 Temperature 
Byte 1 Warning 


Sensor Alarm 


The Sensor Alarm attribute provides 16 bits for the current Sensor Alarm state of the object. 
The Sensor Alarm attribute also maps to the S-Device Supervisor Exception Detail Alarm 
attribute as specified in the Pressure/Vacuum Gauge device profile. The following table 
provides definitions for each Sensor Alarm bit. Reserved bits must be set to zero. 


Data Component Bit 
Sensor Alarm | Reserved | Reserved | Reserved | Reserved | Reserved] Reserved Reserved | Diaphragm 
Byte 0 Failure 


Sensor Alarm | Reserved | Reserved | Reserved | Reserved | Reserved Over Electronics | Reserved 
Byte 1 Temperature | Failure 
of 
Electronics 


Status Extension 


8 Bits providing the current sensor alarm state of the object. 


Reserved | Reserved | Reserved | Reserved | Reserved | Underrange | Overrange | Reading 
Exceeded | Exceeded | Invalid* 


* Note: Logical inversion of Reading Valid 
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SERVICES 


There are no additions or restrictions to the Object Services for this object subclass. 


BEHAVIOR 


For heated sensors, the Sensor Temperature attribute indicates the temperature at which the 
sensor has warmed up. Once the sensor has ”’warmed up”, the Reading Valid attribute of the S- 
Analog Sensor Object will be allowed to be set to TRUE provided that all other conditions 
governing its behavior are also met. The warning bit in the Sensor Warning attribute for Not At 
Temperature shall be cleared. 
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S-ANALOG SENSOR OBJECT INSTANCE SUBCLASS 04 (COLD 
CATHODE ION Gauge) 


OVERVIEW 


Following is a subclass extension to the S-Analog Sensor Object. The original usage for the 
subclass is for Cold Cathode Ion Vacuum Gauges. The Cold Cathode Ion Vacuum Gauge 
extension is used in conjunction with the Vacuum/Pressure Gauge Profile providing control 
and status information. 


A Cold Cathode Ion Vacuum Gauge is a device that measures pressure at vacuum levels. At 
low pressures the operating of these gauges depends upon the establishment of a gas discharge 
between two metal electrodes by the application of a sufficiently high d.c. voltage. The gas 
discharge current is pressure dependent. 


INSTANCE ATTRIBUTES 


Certain minimal implementations may support any optional ’’Set” attributes as ’Get” 
only and still be compliant with this object specification. 


Attr ID Description of Semantics of 
Implementation | Rule Attribute Values 
91 Optional Set V_ |High Voltage |REAL High voltage Volts 
applied to the [default] = 
anode. vendor specific 
92 Optional Set NV |Sensitivity REAL Conversion Factor |[default] = 1.0 
from current ratio |see Semantics 
to pressure section 
93 Required Get V_ |High Voltage |BOOL Indicates whether |0 = Off [default] 
Status the high voltage is |1 =On 
turned on or off. 
Warning BYTE Sensor Warnings —_|see Semantics 
BYTE 
95 STRUCT of [Bit definitions of — |[default=0 
BYTE Sensor Alarms see Semantics 
BYTE 
Optional Get 


96 V_ {Status BYTE Bit mapped byte [default=0] 
Extension providing see Semantics 
additional status of 
an S-Analog Sensor 
instance 


Semantics: 
High Voltage 


Valid values for the High Voltage attribute are manufacturer specific. Attempts to set the High 
Voltage to an invalid value shall return the Invalid Attribute Value error response. 


Sensitivity 


The conversion factor used to convert the ratio of gauge currents to pressure. This conversion is 
manufacturer specific. 
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Sensor Warning 


The Sensor Warning attribute provides 16 bits for the current Sensor Warning state of the 
object. The Sensor Warning attribute also maps to the S-Device Supervisor Exception Detail 
Warning attribute as specified in the Pressure/Vacuum Gauge device profile. The following 
table provides definitions for each Sensor Warning bit. Reserved bits must be set to zero. 


Component 
Sensor Reserved | Reserved | Reserved | Reserved} Reserved Reserved | Reserved | Reserved 
0 
Sensor Reserved | Reserved | Reserved | Reserved | Overpressure | No Ignition | Electronics | Reserved 
Warning Byte High Voltage | Detected Warning 
1 Off 


Sensor Alarm 
The Sensor Alarm attribute provides 16 bits for the current Sensor Alarm state of the object. 
The Sensor Alarm attribute also maps to the S-Device Supervisor Exception Detail Alarm 


attribute as specified in the Pressure/Vacuum Gauge device profile. The following table 
provides definitions for each Sensor Alarm bit. Reserved bits must be set to zero. 


Reserved | Reserved | Reserved | Reserved | Overpressure Over Electronics | Reserved 
High Voltage | Temperature | Failure 
of 
Electronics 


Status Extension 


Data 
Component 


Sensor Alarm 
Byte 0 


Sensor Alarm 
Byte 1 


8 Bits providing the current sensor alarm state of the object. 


Reserved | Reserved | Reserved | Reserved | Reserved | Underrange | Overrange | Reading 
Exceeded | Exceeded Invalid* 


* Note: Logical inversion of Reading Valid 


SERVICES 


The following instance-level services are defined for this subclass of the S-Analog Sensor 
object: 


Service Need in Implementation Service Name Description of Service 
Code 
Class Instance 


62nex n/a Required Set High Voltage State | Sets the high voltage to the state 
specified by the HighVoltageState 
parameter. 
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63 nex Required Clear Overpressure Clears the Overpressure High 
High Voltage Off Voltage Off bit after an automatic 
Alarm high voltage off 


Clear Overpressure High Voltage Off Alarm Service 


If the high voltage is switched off automatically in case of an overpressure condition, it is not 
possible to switch on the high voltage again before the Overpressure High Voltage Off bit is 
reset. This service attempts to reset the Overpressure High Voltage Off bit. See the State Event 
Matrix below. 


Set High Voltage State Service 


Attempts to set the high voltage to the state specified by the HighVoltageState parameter. This 
service may fail depending upon the current object state. See the State Event Matrixbelow. 


Set High Voltage State Service Data Field Parameters 


Parameter Data Type Semantics of Values 
HighVoltageState Required BOOL See 0 = switches high voltage OFF 
Behavior 1 = switches high voltage ON 
BEHAVIOR 


Alarms/Warnings 


If any bit of the attribute ’Sensor Alarm” is set, the high voltage is switched off automatically. 
No ignition detection 


The “No Ignition Detected” bit in the Sensor Warning attribute will be set under the following 
conditions: 


The discharge is undetectable during normal operation. 


Ignition is not detected following an Explicit request to set the High Voltage ON attribute to 
On. 


These conditions are likely to arise when the gauge is operating at very low pressures. 
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Sensor Alarm Detected 
(Overtemperature or elctronics 
failure) 


High Voltage 
Off 


Clear Overpressure 
High Voltage Off 
Alarm Request 


(Success) Clear Overpressure 
Set High Voltage State High Voltage Off 
ON Request (Success) Séjisok Alarhi Econ 
High Voltage eae 
of Overpressure bit is 


reset, but device 
remains in the state 


Sensor Alarm, 
High Voltage Sensor Alarm Detected because of other 
ON Sensor Alarms 


Figure 5-36.1. S-Analog Sensor Object Instance Behavior 


See the S-Device Supervisor object (Chapter 5-35) for more information on the Executing 
State. 


Table 5-36.2. S-Analog Sensor Sub-State Event Matrix 
EVENT SUB - STATE 


High Voltage OFF High Voltage ON Sensor Alarm 
High Voltage Off 


Set High Voltage State ON Request |Transition to High Voltage ON |Error AIRS * Error OSC ** 


Set High Voltage State OFF Request |Error AIRS * Transition to High Voltage | Error OSC ** 
OFF 


Electronics Failure iti k Transition to Sensor Event reported in Sensor 
Alarm Alarm 


High Voltage Off 


Overtemperature Transition to Sensor Event reported in Sensor 
Alarm Alarm 
High Voltage Off 


Clear Overpressure High Voltage Off|Not Transition to 
Alarm Request (Condition: ONLY High Voltage OFF 
Overpressure High Voltage Off in Sensor 
Alarm set) 


Clear Overpressure High Voltage Off|Not Error OSC ** 
Alarm Request (Condition: 
Overpressure Emission Off and other 
Sensor Alarms set) 


Clear Overpressure High Voltage Off|Error AIRS * Error OSC ** Not 
Alarm Request (Sensor Alarms not set) Applicable 


*Error AIRS = Error Response “Already in Requested Mode/State” (Code OBhex) 
**Error OSC = Error Response “Object State Conflict” (Code 0Chex) 
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5-36.11. S-ANALOG SENSOR OBJECT INSTANCE SUBCLASS 05 (HOT 
CATHODE ION GAUGE) 


OVERVIEW 

Following is a subclass extension to the S-Analog Sensor Object. The original usage for the 
subclass is for Hot Cathode Ion Vacuum Gauges. The Hot Cathode Ion Vacuum Gauge 
extension is used in conjunction with the Vacuum/Pressure Gauge Profile providing control 
and status information. 

A Hot Cathode Ion Vacuum Gauge is a device that measures pressure at vacuum levels. It 
contains a hot filament for the generation of free electrons which are accelerated (emission 
current) and, by collision, generate ionized gas molecules. The positive ionized molecules are 
attracted to, and collected by, a negatively charged collector (collector current). The ratio of 
the two currents (collector to emission) is proportional to the pressure. 


Generally, these devices support a ’degas” mode of operation by a resistive method or an 
electron bombardment method. 


INSTANCE ATTRIBUTES 


Certain minimal implementations may support any optional ’’Set” attributes as ’Get” only and 
still be compliant with this subclass specification. All required attributes must be supported as 
specified. 


ID_| Implementation | Rule Type Attribute 
79 | Optional Get V_ | Filament Bias REAL | Diagnostic readout | Volts 
Voltage of filament bias [default] = vendor 
voltage specific 
80 | Optional Set V_ |Grid Voltage REAL | Setting of grid Volts 
voltage. [default] = vendor 
specific 
81 | Conditional Set V_ | Active Degas Indicates which Bit mapped byte of 
See Semantics Filament degas filament is up to 8 filaments as 
selected. specified by the 
Vendor. 
See Semantics 
82. | Optional Set NV | Degas Power REAL | Indicates degas Power in Watts 
power in watts [default] = vendor 
specific 
83 | Optional Get V_ | Filament Current Indicates actual Filament Current in 
filament current in | amps. 
A [default] = vendor 
specific 
84 V_ | Degas Time Off Remaining time, in | [default] =0 
current degas off 
cycle. 
85 | Optional Set NV | Degas Time Off Minimum time, in | [default] = vendor 
Interval seconds, between specific 
consecutive degas See Semantics 
functions. 
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88 | Optional Get 


Attr NV Name | Despont of Semantics of Values 
ID | Implementation Rule Type | Despont 
86 | Optional Get EBT Time On |UINT_ | Remaining time, in | [default] =0 

Remaining seconds, for the See Semantics 
current degas on 
cycle. 

87 | Optional Set V | Degas Time On | UINT | Indicates the length | [default] = vendor 

Interval of time, in seconds, | specific 

that degas is on. See Semantics 


pene | Status BOOL || current 0 = Off 
|| state. 1=On 


Active fall BYTE | Indicates which Bit mapped byte of 
filament(s) is/are up to 8 filaments as 
selected. specified by the 

Vendor. 


See Semantics 


89 | Conditional Set 
See Semantics 


90 | Optional Set NV | Sensitivity REAL | Conversion Factor | [default] = 1.0 
from current ratio to | see Semantics 
pressure section 

91 | Optional Set NV | Emission Current | REAL | Indicates setting Vendor specifies the 
level of emission range of supported 
current in amps. values and the 
Can be indicated in | [default] 
either continuous or | Note: Degas Mode 
discrete readings may override this 
allowed by the setting. 
vendor. 

92 | Optional Set Mode Filament BOOL | Selects automatic or | see Semantics 

Selection user filament 0 = automatic 
selection 1 = user [default] 


93 | Required Get 


Emission Status |BOOL | Indicates whether 0 = Off 
the emission is 1=On 
turned on or off. 


94 | Optional Get Vv Sensor Warning |STRU_ | Bit definitions of [default=0] 
Sensor Warnings see Semantics 


95 | Optional Get Vv Sensor Alarm Bit definitions of [default=0] 
Sensor Alarms see Semantics 

96 | Optional Get Status Extension |BYTE | Bit-mapped byte [{default=0] 
providing additional | see Semantics 
status bits of an S- 
Analog Sensor 
instance. 

Semantics: 


Active Degas Filament 


Indicates which degas filament is active. 0 = off/ 1=on. Filament selection may be made 
either —— — the device, or remotely by setting this attribute. 


| wer | nits | mes | 


Degas Degas Degas Degas Degas Degas Degas Degas 
Filament 8 | Filament 7 | Filament 6 | Filament 5 | Filament 4 | Filament 3 | Filament 2 | Filament | 


5-240 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 5: Object Library 


Release 1.0 


Degas Time Off Interval and Degas Time Off Remaining 


The Degas Time Off Interval attribute specifies the minimum time, in seconds, between degas 
cycles. The valid range for this attribute is manufacturer specific. 


The Degas Time Off Remaining attribute provides the remaining time, in seconds, before a new 
degas cycle can be started. When the Degas Status attribute transitions to the Off state, the 
Degas Time Off Remaining attribute is set to the value of the Degas Time Off 


Interval attribute. The device then decrements the value of the Degas Time Off Remaining 
attribute at one second intervals until the attribute value reaches zero. The “Object State 
Conflict” error response will be returned for all Set Degas State ON requests received while the 
value of the Degas Time Off Remaining attribute is greater than zero. 


Degas Time On Interval and Degas Time On Remaining 


The Degas Time On Interval attribute specifies the maximum time, in seconds, for 
degas. The manufacturer may limit the maximum value for this attribute. 


The Degas Time On Remaining attribute provides the remaining time, in seconds, for the 
current degas cycle. When the Degas Status attribute transitions to the On state, the Degas 
Time On Remaining attribute is set to the value of the Degas Time On Interval attribute. The 
device decrements the value of the Degas Time On Remaining attribute at one second intervals 
and stops the active degas cycle when the attribute value reaches zero. Whenever the Degas 
Status attribute transitions to the Off state from the On state, e.g. alarm detected, Set Degas 
State request received, etc., the Degas Time On Remaining attribute is set to the value zero. 


Active Filament 


Indicates which degas filament is active. 0 = off/ 1 = on. Filament selection may be made 
either automatically by the device, or remotely by setting this attribute. 


Sensor Sensor Sensor Sensor Sensor Sensor Sensor Sensor 
Filament 8 | Filament 7 | Filament 6 | Filament 5 | Filament 4 | Filament 3 | Filament 2 | Filament 1 


Sensitivity 


The conversion factor used to convert the ratio of gauge currents to pressure using the 
following formula: 


P =(1/S) (C/E) 


Where: 

P = pressure (Value attribute) 

S = sensitivity (Sensitivity attribute) 

C = collector current (measured by the device, Amps) 

E = emission current (Emission Current attribute, Amps) 


Sensitivity units are in inverse pressure units. 
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Sensor 


Reserved Reserved Reserved Sensor Pressure Reserved | Electronics 
Warning Byte Warning * | Too High Warning | Maximum 
1 For Degas C/E Ratio 


Mode Filament Selection 


The Mode Filament Selection attribute determines whether devices with multiple filaments 
automatically select the active filament(s) for Emission and Degas ON, or whether the 
user manually selects the filament(s). 


Automatic Filament Selection 


With “Automatic Filament Selection” (Mode Filament Selection attribute = 0), the device 
determines, using a manufacturer specific algorithm, which filament to use for Emission ON 
and Degas ON. When the device is configured for automatic filament selection, the Active 
Filament and Active Degas Filament attributes have Get access. 


If a filament(s) is broken, the corresponding bit(s) in the Sensor Warning attribute is set, and 
the device selection algorithm must avoid selecting the broken filament(s). 


User Filament Selection 


With “User Filament Selection” (Mode Filament Selection attribute = 1), the user selects which 
filament to use for Emission ON and Degas ON. When the device is configured for user 
filament selection: 


The Active Filament attribute has Set access. 


1. The Active Degas Filament attribute has Set access if the device supports individual 
selection of the Emission and Degas ON filaments. If the device uses the same filament 
for Emission and Degas ON, the Active Degas Filament has Get access. 


2. Ifthe user attempts to select a Filament that is broken, the device returns an ’’ Invalid 
Attribute Value” error response. 


For devices that support User Filament Selection Mode and which provide multiple 
filaments, the Active Filament and Active Degas Filament (if the device supports degas) 
attributes are required. The behavior of a device with more than one filament on is device 
specific. Generally, this will not be permitted and attempts to do so will return an error. 


Sensor Warning 


The Sensor Warning attribute provides 16 bits for the current Sensor Warning state of the 
object. The Sensor Warning attribute also maps to the S-Device Supervisor Exception Detail 
Warning attribute as specified in the Pressure/Vacuum Gauge device profile. The following 
table provides definitions for each Sensor Warning bit. Reserved bits must be set to zero. 


Component 
Sensor Sensor Sensor Sensor Sensor Sensor Sensor Sensor Sensor 
Warning Byte | Filament 8 | Filament 7 | Filament 6 | Filament 5 Filament 1 


Exceeded 


* Bit 4 of Byte 1, ’Sensor Warning” relates to error conditions of the filament (cathode), 
anode, and ion collector. 
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Sensor Alarm 


The Sensor Alarm attribute provides 16 bits for the current Sensor Alarm state of the object. 
The Sensor Alarm attribute also maps to the S-Device Supervisor Exception Detail Alarm 
attribute as specified in the Pressure/Vacuum Gauge device profile. The following table 
provides definitions for each Sensor Alarm bit. Reserved bits must be set to zero. 


Data Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
Component 


Sensor Sensor Sensor Sensor Sensor Sensor Sensor Sensor Sensor 
Alarm Byte | Filament 8 | Filament 7 | Filament 6 | Filament 5 Filament 4 Filament 3 | Filament 2 | Filament 1 

0 Alarm Alarm Alarm Alarm Alarm Alarm Alarm Alarm 
Sensor Reserved | Reserved | Reserved | Environment | Overpressure Over Electronics | Exceeded 
Alarm Byte Failure * Emission Off | Temperature | Failure Maximum 


1 of C/E Ratio 
Electronics 


* Bit 4 of Byte 1, ’Environment Failure” relates to environment error conditions of the 
filament (cathode), anode, and ion collector which could cause an automatic emission off. 


Status Extension 
8 Bits providing the current sensor alarm state of the object. 


Reserved | Reserved | Reserved | Reserved | Reserved | Underrange | Overrange | Reading 
Exceeded | Exceeded | Invalid* 


* Note: Logical inversion of Reading Valid 


SERVICES 
The following instance-level services are defined for this subclass of the S-Analog Sensor 
object: 
Service Need in eee Service Name Description of Service 
Code 


61 hex Optional Set Degas State Activate/deactivates degas mode 
according to the parameter Degas State. 
Degas mode may be terminated either 
automatically by device timeout, or 
remotely by this service. 


62 hex Required Set Emission State | Turns the filament on and off according 
to the parameter Emission State 


63 nex n/a Required Clear Emission Off | Clears the Alarm attributes after an 
automatic ’emission off’. This service 
acknowledges and attempts to reset the 
Overpressure Emission Off and Exceeded 
Maximum C/E Ratio and Environment 
Failure Alarm attributes before an 
Emission State ON can be applied. 
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Clear Emission Off Alarm service 


If the emission is switched off automatically in case of an overpressure or any other 
environmental (for example glow discharge) or Exceeded Maximum C/E Ratio condition, it is 
not possible to switch on the emission again before the related Alarm attribute is reset. This 
service resets the Alarm attributes: Overpressure Emission Off and Exceeded Maximum C/E 
Ratio and Environment Failure. See the State Event Matrix in section 5-36.11.2 for additional 
information. 


Set Emission State 


Set Emission State Service Data Field Parameters 


Parameter Data Type Semantics of Values 
EmissionState Required BOOL See Behavior 0 = switches Emission OFF 
1 = switches Emission ON 


Set Degas State 


Set Degas State Service Data Field Parameters 


Parameter Data Type Semantics of Values 
DegasState Required BOOL See Behavior 0= switches Degas OFF 
1 =switches Degas ON 


BEHAVIOR 


Sensor Alarms/Warnings: Filaments 


When the Mode Filament Selection attribute is set to “User or Automatic Filament Selection ”, 
if any bit of the Sensor Alarm attribute is set, the emission is switched off automatically. Ifa 
filament is broken, the corresponding bit in the Sensor Warning attribute is set. 


When the Mode Filament Selection attribute is set to “User Filament Selection’, if the selected 
filament is broken, the corresponding bits in both the Sensor Warning and Sensor Alarm 
attributes are set and the device transitions to the state Sensor Alarm Emission Off . The alarm 
is cleared by selecting a new active filament and the device transitions to the state Emission 
Off: In this case the warning bit remains set and the alarm bit gets cleared. 


When the Mode Filament Selection attribute is set to “Automatic Filament Selection’, the 
device sets all warning bits of all sensor filaments that are broken or failed. If the selected 
filament is broken, the device selects a new filament automatically and sets the warning bit 
of the new failed filament. If all filaments are broken, the corresponding bits in the Sensor 
Alarm attribute are set and the device transitions to the state Sensor Alarm Emission Off 


Sensor Alarm Byte 1: 

Bit 0: Exceeded Maximum C/E Ratio 

In case of an Exceeded Maximum C/E Ratio the device transitions to the state Sensor Alarm 
Emission Off. This error condition has to be acknowledged before the emission could be 


switched on again. This acknowledge is done by the service Clear Emission Off Alarm. After 
receiving this service, the device transitions to the state Emission Off. 
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Bit 1: Electronics Failure 


The device has detected an internal electronics failure which could not be cleared. The 
emission is switched off and the device transitions to the state Sensor Alarm Emission Off- 


Bit 2: Over Temperature of Electronics 


The devices temperature is above its specified range. The emission is switched off and the 
device transitions to the state Sensor Alarm Emission Off and remains there until the 
temperature is below the critical limit. If the user attempts to switch on the emission while this 
bit is set, the error response Object State Conflict is returned. If the temperature goes below the 
critical limit, the device automatically transitions to the state Emission Off. 


Bit 3: Overpressure Emission Off 

In case of an overpressure emission off, the user has to acknowledge the reason of the Emission 
Off situation. The acknowledge is done by the service: Clear Emission Off Alarm. After 
receiving this service, the device transitions to the state Emission Off. 

Bit 4: Environment Failure 

Some other reasons than an overpressure condition (for example grid error or emission current 
being lost to a plasma) may result in an automatic emission switch off. This bit is set after any 
kind of these clearable emission switch off conditions. In this case the device transitions to the 
state Sensor Alarm Emission Off. The service Clear Emission Off Alarm is used to 
acknowledge the error condition and the device transitions to the state Emission Off. 

Sensor Warning Byte 1: 

Bit 3: Pressure Too High For Degas 

If the pressure is above the manufacturer-specified range at which degas is allowed, this bit will 


be set. This bit is cleared if the pressure is below the manufacturer specified range at which 
degas is allowed. 
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5-36.11.1.S-Analog Sensor Object Sub-States for the Executing State 


p = pressure 
Sensor Alarm 
Emission State OFF Detected 
Request (Overtemperature or elctronics/sensor 
(Success) failure) 


Clear Emission Off 
Alarm Request 


ee (Success) or 
ite : Temperature falls 

eques' below over- 
(Success) 


temperature limit 


Emission Sensor Alarm 
State Off Emission OFF 
Request 


(Success) 


Clear Emission Off 
Alarm Request 
a aN (Failure) 
Emission On Alarm bit 0 and/or 3 
No Degas Range and/or 4 are reset, but 
device remains in the 
state Sensor Alarm, 
because of other 


p>pdegas min Sensor Alarms 
conditions. 


p>pdegas min 


Sensor Alarm Detected 


p<=pdegas min 


Emission On > A 


Sensor Alarm Detected 


Degas Range 
A 
Degas State ON Degas State OFF 

Request Request 

(Success) (Success), 
Degas Time On 
Remaining timer 
expires 

Degas On 


Sensor Alarm Detected 
pdegas min = manufacturer specified 


Figure 5.36.4. S-Analog Sensor Object Instance Behavior 


See the S-Device Supervisor object (Volume 1, Chapter 5-35) for more information on the 
Executing State. 


5-36.11.2. S-Analog Sensor Sub-State Event Matrix 
Table 5-36.5. S-Analog Sensor Sub-State Event Matrix 


SUB - STATE 


Emission OFF | Emission ON | Emission ON |Sensor Alarm| Degas On 


No Degas Range| Degas Range | Emission Off 
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EVENT SUB - STATE 


Emission OFF | Emission ON | Emission ON |Sensor Alarm| Degas On 
No Degas Range| Degas Range | Emission Off 


Electronics Failure Transition to Transition to Transition to Event reported | Transition to 
Sensor Alarm Sensor Alarm Sensor Alarm |in Sensor Alarm} Sensor Alarm 
Emission Off Emission Off Emission Off Emission Off 
Overtemperature Transition to Transition to Transition to Event reported Transition to 
Sensor Alarm Sensor Alarm | in Sensor Alarm} Sensor Alarm 
Emission Off Emission Off Emission Off 


Temperature falls below Not Not Transition to Not 
overtemperature limit icable Applicable Applicable Emission Off Applicable 


N 
Appli 

Environmental Failure Transition to Transition to Not Transition to 

like glow discharge Applicable Sensor Alarm Sensor Alarm Applicable Sensor Alarm 
N 
Appli 


Sensor Alarm 
Emission Off 


Emission Off Emission Off Emission Off 


ot 

ot 
Exceeded Maximum C/E ot Transition to Transition to Not Transition to 
Ratio icable Sensor Alarm Sensor Alarm Applicable Sensor Alarm 
Emission Off Emission Off Emission Off 

ot 

ot 


Clear Emission Off Alarm N Not Not Transition to Not 
Request Applicable Applicable Applicable Emission OFF Applicable 
(Condition: ONLY 
Overpressure Emission Off 
and/or Sensor Failure and/or 
Exceeded Maximum C/E 
Ratio in Sensor Alarm set) 

Not Not Error OSC ** Not 
Applicable Applicable | Applicable 


Transition to Transition to Not Transition to 
Sensor Alarm Sensor Alarm Applicable Sensor Alarm 
Emission Off Emission Off Emission Off 


Clear Emission Off Alarm Error AIRS * Error OSC ** Error OSC ** Not Error OSC ** 
Request ail Applicable 
(Sensor Alarms not set) 
Set Emission State On Transition to Error AIRS * Error AIRS * Error OSC ** Error AIRS * 
Request and current pressure | £mission ON 
Set Emission State On Transition to Error AIRS * Error AIRS * Error OSC ** Error AIRS * 
Request and current pressure | /mission ON No 
Set Emission State On Error OSC ** Error AIRS * Error AIRS * Error OSC ** Error OSC ** 
Request 
at a broken filament in case ro | 
of user filament selection 
Emission State On Request Not Applicable Not Applicable Not Applicable | Error OSC ** | Not Applicable 
Current Pressure <= Ignore Event Transition to Ignore Event Ignore Event | Ignore Event 
minimum degas pressure Emission ON 
Degas Range 
Current Pressure <= Ignore Event Transition to Ignore Event Ignore Event Ignore Event 
Degas Range 
Current Pressure > minimum Transition to Transition to 
degas pressure Emission ON No Emission ON No 
Degas Range Degas Range 
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Clear Emission Off Alarm N 
Request Applicable 
(Condition: Overpressure 
Emission Off and/or Sensor 
Failure and/or Exceeded 
Maximum C/E Ratio and 
other Sensor Alarms set) 


Filament Alarm Not 
Applicable 
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Emission OFF | Emission ON | Emission ON |Sensor Alarm| Degas On 
No Degas Range| Degas Range | Emission Off 


Valid Set Degas State On Error OSC ** Error OSC ** Transition to Error OSC ** Error AIRS * 
Set Degas State On Request Error OSC ** Error OSC ** Error OSC ** | Error OSC ** | Error AIRS * 
at a broken filament in case 
of user filament selection 
Set Degas State On Request Error OSC ** Error OSC ** Error OSC ** Error OSC ** | Not Applicable 
and 
Degas Time Off Remaining 
attribute > 0 
Emission ON 
Degas Range 
Degas Time On Remaining Not Applicable Transition to 
attribute decrements to zero Emission ON 
Degas Range 


* Error AIRS = Error Response “Already in Requested Mode/State” (Code OBhex) 
** Error OSC = Error Response “Object State Conflict” (Code 0Chex) 
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S-ANALOG ACTUATOR OBJECT 
Class Code: 32hex 


The S-Analog Actuator Object models the interface to a physical actuator in a device. 
Associated with an analog actuator is a value which is corrected with an offset and a gain 
coefficient, optionally settable in the object before it is output to the physical actuator. 
Manufacturers may specify additional correction algorithms as extensions to this object. 


Additionally, the S-Analog Actuator Object provides two sets of trip-point definitions. The 
behavior associated with these trip points is described in sections below. 


This object is a member of the Hierarchy of Semiconductor Equipment Devices. As such, its 
behavior is managed by the S-Device Supervisor Object. See Section 5-35. 


Class Attributes 


Attribute Need in Access Name Data Type Description of Attribute 
ID implementation | Rule 


These class attributes are optional and are described in Chapter 4 of this specification. 


Reserved by CIP for Future Use 


— 


* Ifthe value of Subclass is 00, which identifies "no subclass", then this attribute is 
OPTIONAL in implementation, otherwise, this attribute is REQUIRED. 


Identifies a subset of additional 
class attributes, services and 
behaviors. 


Subclasses 


Each class level subclass defines a unique meaning for an overlapping range of class attribute 
IDs and/or class service IDs. The range for subclass definitions begins at ID 96 and numbers 
downward for attributes, and ID 63), and numbers downward for services. The subclass for a 
given class is identified by the value of its Subclass class attribute. The subclasses for this 
object are specified at the end of this object specification section. 


Instance Attributes 


Certain minimal implementations may support any optional “Set” attributes as “Get” only and 
still be compliant with this object specification. All required attributes must be supported as 
specified. 


Attr Need in Access | NV Name Data Type Description of Semantics of 
ID | Implementation Rule Attribute Values 
1 {Optional Get NV |Number of Number of The number of 
Attributes supported attributes 
attributes supported by this 
object instance 
2  |Optional Get NV {Attribute List |ARRAY OF  |List of supported |List of attributes 
attribute supported by this 
object instance 
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Attr 
ID 


Need in 
Implementation 


Access Name 


Rule 


Data Type 


NV |Data Units 


See 
Semantics 


3 |Optional 


See 
Semantics 


Set Override 


Set Value 


Status 

Alarm Enable 

NV | Warning 
Enable 


Offset 
Bias 


Gain Data 


Gain 


4 |Optional 


5 |Required 


INT or 
specified by 
Data Type if 
supported 


Required 


7 |Required Get BYTE 


8 |Optional Set BOOL 


9 |Optional Set BOOL 


S 
o 


an 


INT or 
specified by 
Data Type if 
supported 


ptional Set 


INT or 
specified by 
Data Type if 
supported 


11 |Optional Set 


— 
N 


Required if 
Attribute “Gain” 


is other than 
REAL 


REAL or 
specified by 
Gain Data 
Type if 
supported 


13 |Optional 


= 
K< 
uo} 

fo} 


n 
fo) 
o 
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USINT 


ENGUNITS 


USINT 


Data Type Description of 
Attribute 


Determines the 
Data Type of 
Value and all 
related attributes 
as specified in 


this table. 


Determines the 
context of Value 


Specifies an 
override for the 


physical actuator. 


For values other 


than zero (normal 


control), the 
Value attribute is 


Alarm and 
Warning State of 
this object 
instance 


Enables the 


setting of the 
Alarm Bit 


Enables the 
setting of the 
Warning Bit 


An amount to be 
added to Value 
prior to the 
application of 
gain 

An amount to be 
added to Value 
after the 
application of 
gain 

Determines the 
Data Type of 
attribute Gain 


An amount by 
which Value is 
scaled prior to 
driving the 
physical actuator 
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Values 


see Semantics 


section 


[default] = INT 


see Semantics 


section 


({default] = Counts 


0 = normal 


[default] 


see Semantics 


section 


The uncorrected 
value. see 
Semantics section 


[default] = 0 


see Semantics 


section 
[default] 


0 = disable 


[default] 


1 = enable 
0 = disable 


[default] 


1 = enable 


see Semantics 


section 


0 = [default] 


see Semantics 


section 


0 = [default] 


see Semantics 


section 


[default] = REAL 


see Semantics 


section 


1.0 = [default] 
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Attr 
ID 


14 


15 


16 


17 


18 


19 


20 


21 


22 


Need in Access | NV Name Data Type Description of 
— Rule Attribute 


Specifies the 
value of the Gain 
attribute 
equivalent to a 
gain of 1.0 


Required if 


: 


Z 
< 


Z 
< 


Z Z Z 


97-98 |Reserved by CIP for Future Use 


Attribute 12 is 
other than REAL 
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Determines the 
Value above 
which an Alarm 
Condition will 
occur 


Determines the 
Value below 
which an Alarm 
Condition will 
occur 


Determines the 
amount by which 
the Value must 
recover to clear 
an Alarm 
Condition 


Determines the 
Value above 
which a Warning 
Condition will 
occur 


Determines the 
Value below 
which a Warning 
Condition will 
occur 


Determines the 
amount by which 
the Value must 


recover to clear a 
Warning 
Condition 


Specifies the 
behavior of the 
physical actuator 
for states other 
than Execute 


The Value to be 
used for Safe 
State = Safe 
Value 
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Used for 
normalizing the 
Gain attribute. 


see Semantics 
section 


[default] = 


see Semantics 
section 


[default] = 
Maximum value 
for its data type. 


see Semantics 
section 


[default] = 
Minimum value 
for its data type. 


see Semantics 
section 
({default] = 0 


see Semantics 
section 


[default] = 
Maximum value 
for its data type. 


see Semantics 
section 


[default] = 
Minimum value 
for its data type. 


see Semantics 
section 


[default] = 0 


see Semantics 
section 


= [default] 


see Semantics 
section 


= [default] 
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Attr Need in Access | NV Name Data Type Description of Semantics of 
ID | Implementation Rule Attribute Values 


99 |Conditional * Get NV_ |Subclass UINT Identifies a subset ]}0 = No subclass 
of additional 1 — 65535 = 
instance Reserved 
attributes, 
services and 
behaviors. 


* Ifthe value of Subclass is 00, then this attribute is OPTIONAL in implementation, 
otherwise, this attribute is REQUIRED. 


Subclasses 


Each instance level subclass defines a unique meaning for an overlapping range of instance 
attribute IDs and/or instance service IDs. The range for subclass definitions begins at ID 96 
and numbers downward for attributes, and ID 63,,, and numbers downward for services. The 
subclass for a given instance is identified by the value of its Subclass instance attribute. The 
subclasses for this object are specified at the end of this object specification section. 


Semantics: 


Data Type 


All Data Type attributes, including Data Type and Gain Data Type, use the enumerated values 
specified in Appendix C. 


The Data Type attribute is settable only in the /dle State and only if no attribute belonging to 
the object instance is the endpoint of an I/O connection in the Established State. 


The Data Type attribute may change automatically based upon established I/O connections. See 
Behavior section for more information on this mechanism. 


Data Units 

Specifies the context of Value and related attributes (such as, offset and trip points) for this 
object instance. See Appendix D for a list of values. A request to set attribute to an unsupported 
value will return an error response. 

The Data Units attribute is settable only in the /dle State. 

Value, Offset, Gain, Bias and Unity Gain Reference 

The Offset, Gain and Bias attributes are applied to the Value attribute to derive the actual signal 
which drives the physical actuator. The gain is normalized using the Unity Gain Reference 
attribute value. (e.g., for an UINT type Gain, a Unity Gain Reference value may be 10000, 
allowing an effective gain of 0.0001 to 6.5535.) 

The following formula applies: 

physical actuator drive signal = Gainy ¢ ( Value + Offset ) + Bias 


where: Gainy = Gain / Unity Gain Reference 
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There may be additional nonlinear conversions applied to the drive signal as specified by the 
manufacturer. 


Status 


A bit mapped byte which indicates the Alarm and Warning Exception status of the object 
instance. The following definition applies: 


Bit Definition 

0 High Alarm Exception: 0 = cleared; 1 = set 

1 Low Alarm Exception: 0 = cleared; 1 = set 

2 High Warning Exception: 0 = cleared; 1 = set 
3 Low Warning Exception: 0 = cleared; 1 = set 
4 Reserved 

B) Reserved 

6 Reserved 

7 Reserved 


Trip Points and Hysteresis 


Trip Point High is the level above which the Value attribute will cause an Alarm or Warning 
exception condition. 


Trip Point Low is the level below which the Value attribute will cause an Alarm or Warning 
exception condition. 


A Hysteresis value specifies the amount by which the Value attribute must transition in order to 
clear an Alarm or Warning condition. 


For example: A Trip Point High value of 90 and a Hysteresis value of 2 will result in an 
exception condition being set when the Value is above 90 and cleared when the Value drops 
below 88. Similarly, A Trip Point Low value of 90 and a Hysteresis value of 2 will result in an 
exception condition being set when the Value is below 90 and cleared when the Value increases 
above 92. 


Override 


This attribute is used to override the function of the Value attribute in driving the physical 
actuator. The primary application of this feature is in devices where the object instance is being 
driven by another object such as an S-Single Stage Controller object instance. 


The Safe State attribute provides a mechanism for override depending upon object state and 
will take precedents over this. That is, if an object instance implements the Safe State attribute 
and related behavior, then this Override attribute and related behavior will only function in the 
Executing State. 
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Attribute Value State 
0 Normal 
1 Off / Closed 
2 On / Open 
3 Hold 
4 Safe State 
5-63 reserved 
64-127 Device Specific 
128-255 Vendor Specific 
Safe State 


This attribute specifies the behavior of the drive to the physical actuator for states other than 
Executing. See the S-Device Supervisor object definition in Section 5-35. for a description of 
object states. The following values are defined: 


Attribute Value State 
0 Zero / Off / Closed 
1 Full Scale / On / Open 
2 Hold Last Value 
3 Use Safe Value 
4-63 reserved 
64-127 Device Specific 
128-255 Vendor Specific 
Safe Value 


For Safe State set to “Use Safe Value”, this attribute holds the value to which the actuator will 
be driven for object instance states other than Executing. Specifically, this attribute value will 
become the value of the Value attribute. Therefore, the correction formula specified above 
applies. 


Common Services 


The S-Analog Actuator Object provides the following Common Services: 


Service | Need in Implementation Service Name Description of Service 
Code 


OEhex Conditional* | Required Get_Attribute_Single Returns the contents of the 
specified attribute. 
10hex n/a Set_Attribute_Single Modifies an attribute value. 


*The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 


Object-Specific Services 
The S-Analog Actuator Object provides no Object—Specific services. 


Behavior 
The behavior of this object is managed by the S-Device Supervisor Object in Section 5-35.5. 


Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 5: Object Library 


Release 1.0 


An S-Analog Actuator object instance modifies the Value by applying the formula specified 
above with the associated attribute values. Value is specified as Data Type and Data Units. 
Optionally, additional corrective algorithms are applied to further correct for various 
calibration effects. These additional algorithms are specified in other objects, as identified in 
the device profile, or as extensions, specified by the manufacturer. 


All Trip Point calculations, as specified above, utilize the Value attribute before the application 
of Offset and Gain. 


Data Type 


If the implementation of this object specifies more than one valid Data Type value, in the 
device profile or by vendor, then the following behavior with respect to Data Type applies: 

The Data Type value will be set automatically based upon the first valid I/O connection 
established by the device. This configuration will then remain in effect for this object instance 
even after all I/O connections are lost. If, however, a device is specified by a vendor to support 
only one Data Type, this behavior is not supported. 


If no established I/O connections exist, which include an attribute from this object, then the 
Data Type attribute is settable provided that the object is in the dle State. 


The following example demonstrates this behavior: 


A device profile specifies an instance of the S-Analog Actuator object as well as two static 
Assembly object instances, both with data attribute components mapped to this object instance. 
Assembly object instance ID 1 specifies INT data types and Assembly object instance ID 2 
specifies REAL data types. 


After the device is On-Line, it is configured with an I/O connection to Assembly instance ID 2. 
When the connection transitions to the Established State, this object instance attribute Data 
Type is automatically set with the value for REAL before any data is communicated to, or 
from, the object instance. 
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S-SINGLE STAGE CONTROLLER OBJECT 
Class Code: 33 hex 


The S-Single Stage Controller Object models a closed-loop control system within a device. 
Associated with a single stage controller is a Process Variable, a Setpoint and a Control 
Variable. As normally described by classic control theory, a closed-loop controller will drive 
the Control Variable in order to affect the value of the Process Variable such that it is made to 
equal the Setpoint. See the Semantics section, below, for more information regarding these 
variable definitions. Manufacturers may specify additional correction algorithms as extensions 
to this object. 


This object is a member of the Hierarchy of Semiconductor Equipment Devices. As such, its 
behavior is managed by the S-Device Supervisor Object. See Section 5-35. 


Class Attributes 
Attribute Need in Access Name Data Type Description of Attribute 
ID implementation | Rule 


These class attributes are optional and are described in Chapter 4 of this specification. 


Reserved by CIP for Future Use 


* If the value of Subclass is 00, which identifies "no subclass", then this attribute is 
OPTIONAL in implementation, otherwise, this attribute is REQUIRED. 


Identifies a subset of additional class 
attributes, services and behaviors. 


Subclasses 


Each class level subclass defines a unique meaning for an overlapping range of class attribute 
IDs and/or class service IDs. The range for subclass definitions begins at ID 96 and numbers 
downward for attributes, and ID 63;,., and numbers downward for services. The subclass for a 
given class is identified by the value of its Subclass class attribute. The subclasses for this 
object are specified at the end of this object specification section. 


Instance Attributes 


Certain minimal implementations may support any optional “Set” attributes as “Get” only and 
still be compliant with this object specification. All required attributes must be supported as 
specified. 


Need in Access | NV Name Data Type | Description of | Semantics of Values 
Implementation | Rule Attribute 
Optional Get | NV |Numberof |USINT Number of Number of attributes 
i supported supported in this 
attributes object instance 
Get NV [Attribute List |ARRAY OF |Attribute List List of attributes 
USINT supported in this 
object instance 
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Attr Need in Access 
ID | Implementation | Rule 
3 |Optional See NV _ |Data Type USINT 
Seman- 
tics 
4 |Optional See NV |Data Units }|ENGUNITS 
Seman- 
tics 
5 {Optional Set NV_ |Control USINT 
Mode 
6 |Required Set V_ {Setpoint 
specified by 
7  |Conditional * Set V_|Process 
Variable 
8 {Optional Get | NV |CV Data USINT 
Type 
9  |Conditional * Get V_ {Control INT or 
Variable specified by 
CV Data 
: 
; . 
: . 
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NV Name Data Type | Description of | Semantics of Values 
Attribute 


see Semantics section 
({default] = INT 


Determines the 
Data Type of 
Setpoint, Process 
Variable and 
related attributes 


Determines the 
context of the 


See Appendix K 


[default] = Counts 
Process related 
variables such as 
Setpoint and 


Process Variable 
See Semantic section 


[default] = Normal (0) 


Specifies the 
operational mode 
of the controller 


See Semantics 
section. 


The setpoint to 
which the process 


See Behavior section. 
0 = [default] 


The device profile 
must specify the data 
connection for this 
attribute. It may be 
internally linked to a 
sensor. See 
Semantics section. 


0 = [default] 
see Semantics section 
({default] = INT 


Determines the 
Data Type of 
Control Variable 


The drive signal 
output of this 
object. The 
algorithm by 
which this 
attribute is 
calculated is 
manufacturer 
specific. 


The device profile 
must specify the data 
connection for this 
attribute. It may be 
internally linked to an 
actuator. 


[default] = 0 


See Semantics 
section. 


see Semantics section 


[default] = 0 


Alarm and 
Warning State of 
this object 
instance 


Enables the setting 
of the Alarm 
Status Bit 


0 = disable [default] 
1 = enable 


Enables the setting 
of the Warning 
Status Bit 


0 = disable [default] 
1 =enable 
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Attr Need in Access | NV 
ID | Implementation | Rule 

13 |Optional et Number of see Behavior section 
Milliseconds [default] = 0 
allowed for the 
control-loop to 
settle to within the 
error band 


42 
> 
S 
8 


N 
14 N 


V_ {Alarm Error The amount by see Behavior section 


Band [default] = 0 
Process Variable 


15 


Z 
< 


ptional Warning Number of see Behavior section 
Settling Time Milliseconds [default] = 0 


allowed for the 


control-loop to 
settle to within the 
Error Band 


Warning The amount by see Behavior section 


Error Band [default] = 0 


Process Variable 


Safe State Specifies the see Semantics section 
Control Variable 0 = [default] 
behavior for states 
other than Execute 

Safe Value The value to be see Semantics section 

specified by Jused for Safe State}, — [default] 
Data Type if|= Safe Value 
supported 

Ramp Rate Time in 0 = Disabled [default] 
Milliseconds to x = value in 
reach Setpoint milliseconds 

see Behavior section 


Subclass UINT Identifies a subset ]0 = No subclass 
of additional 1 — 65535 = Reserved 
instance attributes, 
services and 
behaviors. 


* — The Process Variable is only optional if this device includes an internal sensor. Otherwise, 
the Process Variable is required. Similarly, The Control Variable is only optional if this 
device includes an internal actuator. Otherwise, the Control Variable is required. 


17 


Z 
< 


Z 
< 


Z Z 


18 |Optional 


19 |Optional 


o o o 
g g 
2. =a 
io) io) 
5 B 
a 2 


16 |Optional 


97-98 |Reserved by CIP for Future Use 
99 |Conditional ** Get 


Z 
< 


** Tf the value of Subclass is 00, then this attribute is OPTIONAL in implementation, 
otherwise, this attribute is REQUIRED. 
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Subclasses 


Each instance level subclass defines a unique meaning for an overlapping range of instance 
attribute IDs and/or instance service IDs. The range for subclass definitions begins at ID 96 
and numbers downward for attributes, and ID 63), and numbers downward for services. The 
subclass for a given instance is identified by the value of its Subclass instance attribute. The 
subclasses for this object are specified at the end of this object specification section. 


Semantics: 
Data Type 


All Data Type attributes, including Data Type and CV Data Type, use the enumerated values 
specified in Appendix C-6.1. 


The Data Type attribute is settable only in the /dle State and only if no attribute belonging to 
the object instance is the endpoint of an I/O connection in the Established State. 


The Data Type attribute may change automatically based upon established I/O connections. See 
Behavior section for more information on this mechanism. 


Data Units 


Specifies the context of Setpoint and Process Variable and related attributes (such as, offset 
and trip points) for this object instance. See Appendix K for a list of values. A request to set 
attribute to an unsupported value will return an error response. 


The Data Units attribute is settable only in the /dle State. 

In applications where this object is used in a relationship with an S-Analog Sensor object, this 
attribute may be specified as Get only, by the device profile or the vendor, where the value 
mirrors that of the S-Analog Sensor object Data Units attribute. 

Setpoint, Process Variable and Control Variable 

These three attributes compose the primary aspects of basic closed-loop control. The Process 
Variable is the measured parameter of the process or system being controlled. The Setpoint is 
the desired value for the measured parameter. By affecting the value of the Control Variable, 
the closed-loop controller drives the process or system to the desired state of: 

Process Variable = Setpoint 

The Control Variable is, therefore, connected to the process or system in such a way that it 


affects the value of the Process Variable. Examples of Control Variable / Process Variable 
combinations include: heater / temperature; valve / flow; or regulator / pressure. 
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Status 


A bit mapped byte which indicates the Alarm and Warning Exception status of the object 
instance. The following definition applies: 


Bit Definition 

0 Alarm Exception: 0 = cleared; 1 = set 

1 Warning Exception: 0 = cleared; 1 = set 
2 Reserved 

3 Reserved 

4 Reserved 

5 Reserved 

6 Reserved 

7 Reserved 

Control Mode 


This attribute is used to override the value of the Control Variable attribute. Further, it may 
cause the object to modify the internal control algorithm such that a smooth, or “bumpless” 
transitions occurs upon activating control to setpoint. 


The Safe State attribute provides a mechanism for override depending upon object state and 
will take precedents over this. That is, if an object instance implements the Safe State attribute 
and related behavior, then this Override attribute and related behavior will only function in the 
Executing State. 


Attribute Value State 
0 Normal 
1 Zero / Off / Closed 
2 Full / On / Open 
3 Hold 
4 Safe State 
5-63 reserved 
64-127 Device Specific (specified by device profile) 
128-255 Vendor Specific 
Safe State 


This attribute specifies what value will be held in the Control Variable attribute for states other 
than Executing. See the S-Device Supervisor object definition in Section 5-35. for a 
description of object states. The following values are defined: 


Attribute Value State 
0 Zero / Off 
1 Full Scale / On 
2: Hold Last Value 
3 Use Safe Value 
4-63 reserved 
64-127 Device Specific (specified by device profile) 
128-255 Vendor Specific 
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Safe Value 


For Safe State set to Use Safe Value, this attribute holds the value to which the Control 
Variable attribute will be set for object instance states other than Executing. 


Common Services 


The S-Single Stage Controller Object provides the following Common Services: 


Service | Need in Implementation Service Name Description of Service 
Code 


OEnex Conditional* | Required | Get_Attribute_Single Returns the contents of the specified 
attribute. 
10hex n/a Set_Attribute_Single Modifies an attribute value. 


*The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 


Object—Specific Services 
The S-Single Stage Controller Object provides no Object—Specific services. 


Behavior 


The behavior of this object is managed by the S-Device Supervisor Object in Section 5-35.5. 
Additionally, this object exhibits the following behavior: 


Alarm and Warning Exception Conditions 


While in the Executing State as defined by the S-Device Supervisor Object: Immediately upon 
detecting that the Setpoint does not equal the Process Variable by an amount plus-or-minus the 
associated (alarm or warning) Error Band, a timer is started. This internal timer is incremented 
as long as the above condition exists. If the timer exceeds the amount indicated by the 
associated (alarm or warning) Settling Time and the associated (alarm or warning) Exception 
Enable is set, then the appropriate (alarm or warning) Exception Condition is set. Note that 
two internal timers are required in order to support both Alarm and Warning Exception 
reporting. 


This behavior is modified for Ramp Rate values not equal to zero. In such cases, the timer is 
not enabled until after the expiration of the Ramp Time (see Behavior description below). 


Ramp Rate 


For Ramp Rate values other than zero, the S-Single Stage Controller Object internally modifies 
the Setpoint value in such a way that the Process Variable is “ramped” to its final value. For 
example: with a Ramp Rate value of 1000, a new Setpoint value will be internally 
(transparently) modified, in whatever time increments the object is able to sustain, in order to 
affect a smooth transition over one second from the old Setpoint to the new Setpoint, finally 
reaching the new Setpoint at the one second mark. 
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Data Type 


If the implementation of this object specifies more than one valid Data Type value, in the 
device profile or by vendor, then the following behavior with respect to Data Type applies: The 
Data Type value will be set automatically based upon the first valid I/O connection established 
by the device. This configuration will then remain in effect for this object instance even after 
all I/O connections are lost. If, however, a device is specified by a vendor to support only one 
Data Type, this behavior is not supported. 


If no established I/O connections exist, which include an attribute from this object, then the 
Data Type attribute is settable provided that the object is in the /dle State. 


The following example demonstrates this behavior: 


A device profile specifies an instance of the S-Single Stage Controller object as well as 
two static Assembly object instances, both with data attribute components mapped to this 
object instance. Assembly object instance ID 1 specifies INT data types and Assembly 
object instance ID 2 specifies REAL data types. 


After the device is On-Line, it is configured with an I/O connection to Assembly instance 
ID 2. When the connection transitions to the Established State, this object instance 
attribute Data Type is automatically set with the value for REAL before any data is 
communicated to, or from, the object instance. 


Control 


The application of this object is further specified in the applicable device profile; primarily, the 
interfaces and object relationships are defined. Generally, the Process Variable attribute is 
restricted to "Get Only" access and an internal connection is defined to another object. 
Similarly, the Control Variable is generally not supported due to internal connections. 


When in the EXECUTING state, this object is running an application process designed to cause 
the Process Variable to be driven to the value of the Setpoint. In any state other than 
EXECUTING, the application process is stopped and the Safe State is activated for the output 
of the object. 


Any fault detected by the object application process causes the object to transition to the 
appropriate state as defined by the managing S-Device Supervisor object. 
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S-GAS CALIBRATION OBJECT 
Class Code: 34hex 


An S-Gas Calibration Object affects the behavior of an associated S-Analog Sensor object 
instance; a device profile will show a relationship between these two objects where an S-Gas 
Calibration Object is used. The S-Analog Sensor object uses a selection attribute as the gas 
type selection mechanism. The S-Gas Calibration Object provides the data with which a device 
enacts the appropriate calibration algorithm for a given gas type. Each S-Gas Calibration 
Object Instance contains a set of attribute values for one particular calibration set; each 
identified by the Gas Standard Number. 


The S-Gas Calibration class level object provides a service for retrieving a list of all valid 
object instances. The service response includes a list of elements. Each element includes: 
Instance ID, Gas Standard Number and the valid S-Analog Sensor object instance ID for which 
the instance is valid. 


There may be more than one instance with the same Gas Standard Number. These instances 
may be differentiated by Full Scale, Gas Symbol, Additional Scaler and/or other parametric 
distinctions, including valid S-Analog Sensor object instance ID. The distinctions may, or may 
not, be evident in the Get_All_Instances service response, depending upon what the distinction 
is. 


S-Gas Calibration Objects most often utilize the region of Manufacturer Specified Attributes 
(ID > 100) for specific calibration parameters. 


This object is a member of the Hierarchy of Semiconductor Equipment Devices. As such, its 
behavior is managed by the Device Supervisor Object. See Section 5-35. 


The S-Gas Calibration object makes use of a list of Standard Gas Type Numbers. This list is 
described in publication: 


SEMI E52-95 “Practice for Referencing Gases Used in Digital Mass Flow Controllers”, 
Semiconductor Equipment and Materials International (SEMI), Mountain View, CA 94043- 
4080. 


NOTE: It is implied that the reference above is to the latest revision as specified by SEMI. 
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Class Attributes 


Need in Access Name Data Type 
implementation | Rule 


These class attributes are optional and are described in Chapter 4 of this specification. 
Reserved by CIP for Future Use 


a 


* Ifthe value of Subclass is 00, which identifies "no subclass", then this attribute is 
OPTIONAL in implementation, otherwise, this attribute is REQUIRED. 


Attribute 
ID 


Description of Attribute 


Identifies a subset of additional 
class attributes, services and 
behaviors. 


Subclasses 


Each class level subclass defines a unique meaning for an overlapping range of class attribute 
IDs and/or class service IDs. The range for subclass definitions begins at ID 96 and numbers 
downward for attributes, and ID 63), and numbers downward for services. The subclass for a 
given class is identified by the value of its Subclass class attribute. The subclasses for this 
object are specified at the end of this object specification section. 


Instance Attributes 


Certain minimal implementations may support any optional “Set” attributes as “Get” only and 
still be compliant with this object specification. All required attributes must be supported as 


specified. 
Need in Access] NV Name Description of 
Implementation | Rule Attribute 
Optional Get |NV_ |Number of USINT Number of 
Attributes attributes supported 
Optional Get |NV_ |Attribute List JARRAY OF _ |List of attributes 
USINT supported by this 
object instance 


Required Get |NV_ |Gas Standard |UINT Gas Type Number |([default] = 0 (no gas 
Number type specified) 
see Semantics section 
Required Get |NV_ |Valid Sensor INT S-Analog Sensor |0 = No Valid Sensor 
Instance object instance ID |n = Instance ID 
for which this _ see Semantics section 
object instance is [default] = 0 
valid : 


Optional Set |NV_ |GasSymbol |SHORT Gas Type Name see Semantics section 
STRING 


[default] 
Optional Get |NV_ |Full Scale STRUCT of: |Full Scale of the 


Semantics of Values 


= null 


see Semantics section 
device using this [default] = 0, 0 
object instance : 


Amount The amount of 

measured parameter 
corresponding to full 
scale. 


Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 5: Object Library 
Attr Need in Access| NV Name Data Type Description of Semantics of Values 
ID_ | Implementation | Rule Attribute 


ENGUNITS — {Units The units for the 
above. 
see Data Units 
Appendix K 


7 |Optional Set | NV_ |Additional Additional In addition to the 

Correction Factor |correction algorithm, 
this amount is 
multiplied to the 
reading. Generally 
used for Gas 
Correction for a gas 
other than the type 
identified for the 
object instance by 
attribute 3. 


(e.g., scale a nitrogen 
object instance to 
measure argon). 


Default = 1.0 


8  |Optional Calibration Date of Calibration |The date this object 
Date instance was last 


calibrated 
[default] = 0 


9  |Optional Calibration Calibration Gas The gas number of the 
Gas Number gas used to calibrate 


this object instance. 


({default] = 0 


10 {Optional Get Gas Gas Correction [default] = 1.0 
Correction Factor 


Factor For devices that 


support simple 
correction factors 
(as opposed to 
algorithms) for gas 
selection. 


95-96 |Defined by Subclasses below 
97-98 |Reserved by CIP for Future Use 


99 |Conditional* |Get |NV_ |Subclass UINT Identifies a subset |0 = No subclass 
of addivenal 1 = Standard T & P 
instance attributes, 
caiceenid 2 — 65535 = Reserved 
behaviors. 


* If the value of Subclass is 00, then this attribute is OPTIONAL in implementation, 
otherwise, this attribute is REQUIRED. 
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Subclasses 


Each instance level subclass defines a unique meaning for an overlapping range of instance 
attribute IDs and/or instance service IDs. The range for subclass definitions begins at ID 96 
and numbers downward for attributes, and ID 63), and numbers downward for services. The 
subclass for a given instance is identified by the value of its Subclass instance attribute. The 
subclasses for this object are specified at the end of this object specification section. 


Semantics: 
Gas Standard Number 


Used to identify a gas standard number, for which the object instance is currently calibrated. 
See Instance Application Example below. 


The actual coding of the values are described in the following publication: 


See introduction section (above) for reference to the SEMI publication: “Practice for 
Referencing Gases Used in Digital Mass Flow Controllers”. 


Since the actual attributes, and their context, for the parameterization of object instances for 
particular gas types is beyond the scope of this standard (i.e., vendor specific) the Access Rule 
for this attribute has been specified as Get. Vendors may choose to specify an Access Rule of 
Set for this attribute. 


Valid Sensor Instances 


This attribute specifies the S-Analog Sensor object instance for which the S-Gas Calibration 
object instance is valid. An S-Gas Calibration object instance will be valid for zero or one S- 
Analog Sensor object instances. 


Gas Symbol 


This optional attribute is a string coded representation of the name of the gas for which the 
object instance has been configured. It is coded as a user defined text symbol or it is coded as 
defined in the above referenced SEMI publication. 


This attribute may indicate a different gas from the one which has been specified by the Gas 
Standard Number. See Instance Application Example below. 


Full Scale 


This optional attribute identifies the amount of measured parameter (e.g., Mass Flow) 
corresponding to the Full Scale of the associated S-Analog Sensor object. A primary purpose 
for this attribute is to allow for simple S-Analog Sensor object implementations where the 
Value is reported in raw units; this attribute allows a mapping to engineering units. 


For example, the Full Scale for a S-Gas Calibration object may be 100 sccm, while the Full 


Scale for the associated S-Analog Sensor object may be 20,000 counts (1.e., S-Analog Sensor 
object Data Type = INT and Data Units = Counts). 
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Instance Application Example 


The following is an example to demonstrate the usage of Gas Calibration object instances and 
their attributes: 


A device has been supplied with three gas calibration object instances: nitrogen (13)*, helium 
(1)* and argon (4)*. The user wishes to use the device for silane (39)* and knows that a 
correction factor of 0.60 will properly convert a nitrogen calibration for this application. The 
object instance for nitrogen would be selected and the Additional Scaler attribute for this 
instance would be set to 0.60. To identify this modification, the Gas Symbol may be set to read 
“silane”, “SiH4”, or “39”. 


* (Gas Standard Number) 


5-39.3. Common Services 


The S-Gas Calibration Object provides the following Common Services: 


Service | Need in Implementation Description of Service 
Code 


OEhex | Required Required Get_Attribute Single | Returns the contents of the 
specified attribute. 


10hex Set_Attribute Single | Modifies an attribute value. 


5-39.4. Object—Specific Services 


Service Need in Implementation Service Name Description of Service 


Code 


4Bhex Required n/a Get_All_ Instances Requests a list of all available 
object instances with their 
respective gas numbers 


Success Response Service Data Field Parameters 


Parameter Data Type Semantics of Values 
Size of List Required UINT Specifies the number of | Number of gas 
elements in the Array calibrations in the list 
List of Gas Required if | ARRAY of Supported List The list of gas calibrations 
Calibrations | Size>0 


Object Instance ID 
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S-Gas Calibration Object Behavior 


The behavior of this object is managed by the Device Supervisor Object, defined in Section 5- 
30,0; 


S-Gas Calibration Object Instance Subclass 01 (Standard T & P) 


The following specification applies to a subclass of this object for application in Mass Flow 
Controller devices. 


INSTANCE ATTRIBUTES 


The following Instance Attributes are specified for this object subclass 01. 


Attr Need in Access Name Data Type Description of | Semantics of Values 
ID Implementation Rule Attribute 


95 | Optional Get Calibration REAL The gas pressure in | The Standard 
Pressure KiloPascal Pressure with respect 
to the calibration 
conditions. 
Default = 101.32 
96 | Optional Get Calibration REAL The Gas The Standard 
Temperature Temperature in Temperature with 
Degrees C respect to the 
calibration 
conditions. 
Default = 0.0 


SERVICES 


There are no additions or restrictions to the Object Services for this object subclass. 


BEHAVIOR 


There are no additions or restrictions to the Behavior for this object subclass. 


Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 5: Object Library 


5-40. TRIP POINT OBJECT 
Class Code: 35hex 


The Trip Point Object models the action of trip points for a device, often corresponding to 
physical outputs (Discrete Output Object). Each Trip Point instance has a source pointer (an 
attribute of data type Packed EPATH referencing an input value) and a destination pointer (an 
attribute of data type Packed EPATH referencing a discrete output value). A trip point value, 
designated as a High or Low trip point, is compared to the specified source value. This trip 
point is intended to be used as a process control indicator. 


5-40.1. Class Attributes 


Name 


Attribute 
ID 


Need in Access 
Implementation | Rule 


Data Type Description of Attribute 


These class attributes are optional and are described in Chapter 4 of this specification. 
Reserved by CIP 


* Ifthe value of Subclass is 00, then this attribute is OPTIONAL in implementation, 
otherwise, this attribute is REQUIRED. 


Identifies a subset of additional 
attributes, services and 
behaviors. The subclasses for an 
object are specified at the end of 
the object specification section. 


Subclasses 


Each class level subclass defines a unique meaning for an overlapping range of class attribute 
IDs and/or class service IDs. The range for subclass definitions begins at ID 96 and numbers 
downward for attributes, and ID 63),., and numbers downward for services. The subclass for a 
given class is identified by the value of its Subclass class attribute. The subclasses for this 
object are specified at the end of this object specification section. 


Name Data Type Description of Semantics of 
Attribute Values 
Number of | USINT Number of attributes 
Attributes supported 
NV | Attribute ARRAY OF | List of attributes 
List USINT supported by this 
object instance 


5-40.2. Instance Attributes 
Attr Need in Access 
ID Implementation | Rule 
ea 

. mF 


3 Conditional High Trip | INT or based | Defines the Value at | [default = 0] 


Point Data Type __| or above which a trip 
attribute, if | point condition will 
supported. occur 


See Semantics 
section 


[At least one of 
attributes 3 or 5 
are required. ] 
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Attr Need in Access | NV 
ID Implementation | Rule 


Optional NV _ | High Trip 


Enable 


& 


BOOL Enables the High 
Trip Point setting. 


NV 


INT or based 
Data Type 


Defines the Value at 
or below which a trip 
point condition will 
occur 


5 Conditional 


Low Trip 


Point 
[At least one of 


attribute, if 
supported. 


BOOL Enables the High 
Trip Point setting. 


a ; 
Status BOOL State of this object 

instance 

Ss NV | Polarity BOOL Polarity of Output as 
derived to Status. 

Set NV _ | Override USINT Specifies an override 
Status. 
Note: This attribute 
may also be set 
internally by the 
device during 
different States. 


Set NV |Hysteresis | Same as 
High/Low 
Point Data 
Type 
: 
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attributes 3 or 5 
are required. ] 


6 Optional 


Low Trip 
Enable 


Set 

Set 

Set 

7 Required Get 
et 


8 Optional 


Optional 


— 
Co 


\o 


Determines the 
amount by which the 
Input must recover to 
clear a trip point 
condition 


Optional 


11 ‘| Optional 


Specifies the amount 
of time a trip 
condition must exist 
before it is reported 
to Status 
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Name Data Type Description of 
Attribute 


Semantics of 
Values 


[default=enabled] 


See Semantics 
section 


[default=0] 


See Semantics 
section 


[{default=enabled] 


See Semantics 
section 

0 = trip point 
condition does not 
exist (unasserted) 
1 =trip point 
condition exists 
(asserted) 


See Semantics 
section 


0 = Normal 
(Output = Status) 


1 = Reverse 
(Output = Status 
inverted) 


See Semantics 
section 


0 = Normal 

1 = Force FALSE or 
unasserted 

2 = Force TRUE or 
asserted 

3 = Freeze Status 
and Output at 
existing values 

4 — 255 = Reserved 
by CIP 


See Semantics 
section 


({default=0] 


Time in 
milliseconds 


See Semantics 
section 


[default=0] 
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Attr Need in Access | NV Name Data Type Description of Semantics of 
ID Implementation | Rule Attribute Values 
12 


Required Set NV | Destination | Packed Specifies the path of | See Semantics 
EPATH the destination 
attribute whose value 
will be set by Output 


13 | Required Get V_ | Output BOOL Output of the object |= Status as a 
the value of which is | function of Polarity 
sent to destination 

See Semantics 

14 | Required Set NV_ | Source Packed Specifies the path of | See Semantics 

EPATH the source attribute 
whose value is 
retrieved for Input 
15 | Required Set V_ | Input INT or Input to the object See Semantics 
specified by | whose value is 
Data Type | retrieved from source 
16 


Optional NV |Data Units | ENGUNITS | Units of Input, Trip | See Semantics 
Point, Hysteresis, etc. 

Optional NV | Data Type | USINT Data Type of Input, | [default] = INT 
Trip Point, Hyseresis, ; 
etc. See Semantics 


97 - 98 | Reserved by CIP 


Conditional Get NV_ | Subclass UINT Identifies a subset of |0=No subclass 
additional attributes, 
services and n= subclass as 
behaviors. The defined herein 
subclasses for this 
object are specified at 
the end of this object 
specification section. 


Subclasses 


Each instance level subclass defines a unique meaning for an overlapping range of instance 
attribute IDs and/or instance service IDs. The range for subclass definitions begins at ID 96 
and numbers downward for attributes, and ID 63,,,; and numbers downward for services. The 
subclass for a given instance is identified by the value of its Subclass instance attribute. The 
subclasses for this object are specified at the end of this object specification section. 


Semantics: 

High/Low Trip Point, Enable and Status 

High or Low Trip Point is compared to the /nput value to generate a trip point condition. 

If a single trip point for this instance is required, either the High or Low Trip Point may be 
enabled, determining not only the direction of the trip point, but also the direction of hysteresis. 


If two or more separate trip points are required, each exhibiting a separate Status, then two or 
more instances of this object are required. 
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A trip region can be established with only one instance by enabling both High and Low 
settings. Status will be set if the input value is at or below the Low Trip Point OR at or above 
the High Trip Point, cleared if the input value lies between the trip points. 


Hysteresis and Delay 


The Delay value specifies how long the trip condition must exist or clear before it is reported in 
Status. The Hysteresis value specifies the amount by which the Input value must transition in 
order to clear a trip point condition. 


The following relationships demonstrate the logic for a High Trip Point with Hysteresis and 
assumes the use of an internal Timer: 


For Status not set: 

If (uput >= Trip Point High) and (Timer not running) 
Then start a Timer 

If Unput >= Trip Point High) and (Time >= Delay) 
Then set Status 

If Unput < Trip Point High - Hysteresis) and (Time < Delay) 
Then reset Timer 


For Status set: 

If Unput < Trip Point High - Hysteresis) and (Timer not running) 
Then start a Timer 

If Unput < Trip Point High - Hysteresis) and (Time >= Delay) 
Then clear Status 

If Unput >= Trip Point High) and (Time < Delay) 
Then clear Status 


Example: High Trip Point = 100, Hysteresis = 2, and Delay = 1000: will result in a trip point 
condition being set when the /nput stays at or above 100 for 1 second and cleared when /nput 
drops below 98 for 1 second. Similarly: Low Trip Point = 100, Hysteresis = 2, and a Delay = 
1000: will result in a trip point condition being set when Jnput falls at or below 100 for 1 
second and cleared when /nput increases above 102 for 1 second. 


Data Type and Data Units 

Specifies the context of /nput and related attributes (such as Hysteresis) for this object instance. 
Data Units and Data Type will match the source attribute's Data Units and Data Type. See 
Appendix J for Data Type definitions and Appendix K for Data Units (ENGUNITS) definition. 
Polarity and Output 

The value of the Output attribute is derived by combining the value of the Status attribute with 
that of the Polarity attribute. For a Polarity value of Normal, the Output will equal the value of 
Status. For a Polarity value of Reverse, the Output will equal the value of Status inverted. The 
following relationships demonstrate this logic: 


For (Polarity = 0): Output = Status 


For (Polarity = 1): Output = Status Inverted 
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The Polarity attribute is optional and is anticipated to be used only to overcome a hardware 
limitation. 
Source and Input 


The Source attribute defined as data type Packed EPATH (see CIP Common Specification, 
Appendix C), specifies the path for the input whose value is retrieved and becomes the value of 
Input. 


Destination and Output 


The Destination attribute, defined as data type Packed EPATH (see CIP Common 
Specification, Appendix C), specifies the path for the output whose value is set with the value 
of Output. 


5-40.3. Common Services 


The Trip Point Object provides the following Common Services: 


Service Need in Implementation Service Name Description of Service 
Code 


OEpex | Conditional * | Required Get_Attribute_ Single | Returns the contents of the 
specified attribute. 
10hex Set_Attribute Single | Modifies an attribute value. 


* The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 


5-40.4. Object—Specific Services 
The Trip Point Object provides no Object-Specific services. 


5-40.5. Behavior 
5-40.5.1 Trip Point Object States 
Figure 5-40.1. Trip Point Object State Transition Diagram 


Power Applied or Reset 


| 


Idle 


Activated | Deactivated 


Executing 


Table 5-40.2. DS Instance Behavior State Description 


State Description 
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EXECUTING | The Object instance is performing its normal functions. 
IDLE The Object instance is not performing its normal function. 


The STATUS attribute is NOT ASSERTED 


Internal requests are coordinated such that the EXECUTING state here will align with the 
OPERATIONAL state of the Identity object as well as the EXECUTING state of the S-Device 
Supervisor object in devices where these objects coexist. Transitions to all other states by these 
objects will cause this object to transition to its IDLE state. 


The Activated and Deactivated events correspond to Identity Object events. Where this object 
is used with an S-Device Supervisor object (see Chapter 5-35), these events are similarly 
aligned, but further include alignment with S-Device Supervisor events as specified in Chapter 
5-35. 


5-40.5.2 Trip Point Object State Event Matrix 
Table 5-40.3. State Event Matrix for S-Device Supervisor Object 


EVENT 
Power Applied Default Entry Point at ee = 


Identity Object Transition to EXECUTING State Ignore Event 
Transition to Operation state 
(as by an Activated event) 


Identity Object Ignore Event Transition to IDLE State 
Transition from Operation state 
(as by a Deactivated event) 


S-Device Supervisor Object Transition to EXECUTING State Ignore Event 

Transition to Executing State 

S-Device Supervisor Object Ignore Event Transition to IDLE State 
Transition from Executing State 
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5-41. DRIVE DATA OBJECT 


Class Code: not assigned 


"This Section is being Reserved for the Drive Data Object." 
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5-42. CONNECTION CONFIGURATION OBJECT 
Class Code: F3hex 


This object defines an interface used to create, configure and control CIP connections on a host 
device. This specification does not define or constrain the operation of the host device’s 
connection management state machine. 


5-42.1. Class Attributes 


Attribute Need in Access Name Data Type Description of Attribute 
ID Implementation | Rule 


3 Required Get Num Instances | UDINT Number of connections currently 
instantiated 


4 thru 7 | These class attributes are optional and are described in Chapter 4 of this specification. 


8 Required Get Format Number | UINT This number determines the format of 
instance attribute 9. Format_numbers 
in the range 0-99 are to be defined in 
this standard. Format_numbers in the 
range 100-199 are vendor specific. All 
other format_numbers are reserved and 
shall not be used. 

9 Required Set Edit Signature | UDINT Created and used by configuration 
software to detect modifications to the 
instance attribute values 

The additions made to this Object with revision 2 are: 

Definition of Connection Status attribute for target-side, peer-to-peer connections 

In the Connection Flags Attribute defined bits 4-6 for “T=>O Real time transfer format”. 
Changed the name of bits 1-3 from “Idle Style” to “O=>T Real time transfer format” and 


defined the value=3 for “Heartbeat” 


Changed the Object Specific service Get Status from optional to required, and changed the 
Set Attribute Single service from required to optional. 


Added Instance attribute 11, Proxy Device ID. Updated the Get_Attribute_All response and 
Set_Attribute_all request to include attribute 11. 


5-42.2. Instance Attributes 


Need in Access | NV Name Data Description of Semantics 
Implementation | Rule Type Attribute of Values 


Required Get V_ | Connection Status | Struct of | When a connection is See Table 
not OPEN, this attribute | 5-262 for 
tells you why. details 

Osi 
reserved USINT | Reserved Shall be 
zero 
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Attr Need in Access | NV Name 
ID | Implementation | Rule Attribute of Values 
5-263 


3 | Required Set NV | Target Device ID | Struct of | Device identification 
used by configuration 
software to identify 
target device associated 
with this instance 

vendor_id UINT Vendor ID 
product_type UINT Device Type 
product_code UINT Product Code 


This connection’s 
ControlNet Scheduling 
read data 
connection_index 
number as assigned by 
the configuration 
software. 


Required NV |Net Connection — | Struct of 

Parameters 

conn_timeout USINT _ | Connection Timeout 
Multiplier 

xport_class_and t} BYTE Transport Class and 

rig Trigger 

rpi_OT DINT | Originator to Target 
Requested Packet 
Interval 

net_OT INT Originator to Target 
network connection 
parameters 

rpi_TO DINT | Originator to Target 
Requested Packet 
Interval 

net_TO INT Originator to Target 
network connection 


parameters 
Set NV | Connection Path” 
open_path_size 
reserved 
open connection 
path 


7 | Required Get NV | Config #1 Data” | Struct of 


Data Description of Semantics 


S 
5 = 
5 = 


ec 


zi 


| 


Struct of 
USINT 


Open connection path | Number of 
size 16 bit 
words. 


USINT | Reserved Shall be 
Zero 


Padded | Connection path used in 
EPATH | the Forward Open 


a 


service of the 
Connection Manager. 
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Implementation | Rule 


8 | Required 


Description of Semantics 
Attribute of Values 


config data_size | UINT Length of config data 
in bytes. 
config data Array of | Config # 1 data 
octet 


name_size USINT | Number of characters in 
the connection name. 
reserved USINT _ | Reserved Shall be 
zero 


User-assigned 


connection name 
encoded in UNICODE. 


9 | Required Set NV |Implementation | Struct of 
Defined Attribute 
format_number UINT This number determines | 0-99 
the format of this Reserved 
attribute. 100 — 199 
Vendor 
Specific 
All other 
values are 
reserved. 
impl_defined_dat Size, in bytes, of 
a_ implementation defined 
size attribute data that 
follows 
impl_defined_dat | Array of | Implementation defined 
a octet attribute data specific to 
a particular 
implementation. 
Strack of | 
Sisto 


10 | Required NV | Config #2 Data” Pe 
config data size | UINT 
in bytes. 
config data Array of 
octet 
11 | Required NV | Proxy Device ID 
vendor_id 
product_type 
product_code 
major_rev 
minor_rev 


UINT Vendor ID 
' This attribute is required for a device on ControlNet; otherwise this attribute shall not be supported. 


n 
= 
¢ 
te) 
3 
° 
= 


> The data from attributes 7 and 10 are concatenated (in that order) into a single data segment, then appended to 
the connection path in attribute 6 to form the complete path sent in the Forward Open service of the Connection 
Manager object. 
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Table 5-42.1. Connection Status Values 


General | Description Extended | Description 
Status Status 
0x00 If originator-side connection Various Connection is open 
entry, then Success 


Else if target-side connection Connection is idle 
entry, then see Extended 
Status for more information 


0x01 or If producing data, then number of peer 
greater consumers 
0x01 Connection Failed Various Extended status as defined by part 4, Network 
and Transport Layer 
Various Other general status values Various Extended status as defined by part 4, Network 
(0x02 — x26) and Transport Layer 
0xDO Connection configuration 0x0001 Connection is closed or stopped (via the Close 
object-specific general status or Stop services) 
0x0002 Connection open is pending 
0x0003 Connection close is pending 


Table 5-42.2. Connection Flags Attribute Definition 


Bit Meaning 
0 Connection 


0 = Originator 
1 = Target 
L338 O=>T Real time transfer format 
0 = Use 32-bit Run/Program header to indicate idle mode. 
1 = Use zero data length packet to indicate idle mode. 
2 = None. Connection is pure data and is modeless. 
3 = Heartbeat. 
Other values are reserved for future use. 
4-6 T=>O0 Real time transfer format 
0 = Use 32-bit Run/Program header to indicate idle mode. 
1 = Use zero data length packet to indicate idle mode. 
2 = None. Connection is pure data and is modeless. 
3 = Heartbeat. 
Other values are reserved for future use. 


7-15 Reserved 
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5-42.3. Common Services 


The Connection Configuration Object provides the following Common Services: 


Service Need in Service Name Description of Service 
Code Implementation 


Class Instance 


Required Get_Attribute_Al | Gets all attributes of the specified 
l instance. 


Required Set_Attribute_All | Sets all attributes of the specified 
instance. 
N/A Creates a new connection instance. 


Required _| Delete Deletes an existing connection 
instance. 
Required Get_Attribute_Si | Returns the contents of the specified 
ngle attribute. 


Optional Set_Attribute Sin | Modifies an attribute value. 
gle 
Required Restore current connection attributes. 


5-42.4. Object Specific Services 


The Connection Configuration Object provides the following Object Specific Services: 


Olnex | Required 


O2hex | Optional 


O8hex | Required 


O9bex | Required 


OEpex | Optional 


10hex | Required 


1Spex | Required 


Service Need in Service Name Description of Service 
Code Implementation 


Class Instance 


4Bhex |Required |N/A Kicks Edit Watchdog Timer 
4Chex | Optional | Optional Opens connections 

Optional Closes connections 

4Ehex | Optional | Optional Stops connections 

4Fhex |Required |N/A Manages session editing 

50hex |Required |N/A Get status for multiple connections 
S5ihex |Required |N/A Completes session editing 

52hex |Required |N/A Audits pending changes 


4Dhex | Optional 
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Get_Attribute_All (Service Code 0x01) 


This service shall read all attributes associated with an existing instance and shall support the 
following error codes: 


General Status 


0x04 
0x05 
0x08 


Name 


Connection 
Status 


Connection 
Flags 


Target Device 
Id 


CS Data 
Index 
Number 


Net 
Connection 
Parameters 


Connection 
Path 


Config #1 
Data 


Extended Error Description 
Status 


Instance undefined 
Unimplemented service 


The structure of the Get_Attribute_All response is shown in the table below. 


Data Type 
Struct of 


USINT 

USINT 

UINT 
WORD 


Struct of 
UINT 
UINT 
UINT 
USINT 
USINT 

UDINT 


Struct of 


SINT 
BYTE 
DINT 
I 
DINT 
INT 


eG eve 
Z 
4 


Ee 


Struct of 
SINT 


SINT 


Array of 
UINT 


Struct of 


Description 


Connection status information. When the connection is not open, this attribute 
contains an error code indicating the reason. 


General status. 
Pad. 
Extended status. 


Connection Flags. 


Target Device identification. 
Vendor Id 

Product Type 

Product Code 

Major Revision 

Minor Revision 


ControlNet Scheduling object read data connection_index number. The default 
value used when this attribute is not supported shall be OxFFFFFFFF. 


Network connection parameters for both originator-to-target and target-to- 
originator directions. 


The connection time-out multiplier. 

Transport class and trigger. 

Originator-to-target RPI. 

Originator-to-target network connection parameters. 
Target-to-originator RPI. 

Target-to-originator network connection parameters. 
The connection path. 


Size of connection path, in 16-bit words, used in the Connection Manager 
Forward Open request service 


reserved. shall be zero 


The connection path. The open connection path size is the length of this array. 


Config #1 data. This data is sent to devices via the Connection Manager 
Forward Open request service 
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Name 


Config #2 
Data 


Connection 
Name 


Implementati 
on Defined 
Attribute 


Proxy Device 
Id 


Data Type 
UINT 


Array of 
USINT 


Struct of 
UINT 


Array of 
USINT 


Struct of 
USINT 
USINT 
STRING2 

Struct of 
UINT 
UINT 


Array of 
USINT 


Struct of 
UINT 
UINT 
UINT 
USINT 
USINT 
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Description 


configuration data length in bytes. 


configuration data. Padded to an even number of bytes. 


Config #2 data. This data is sent to devices via the CM_open_request service 
configuration data length in bytes. 


Module configuration data. Padded to even number of bytes. 


The connection name. 

Number of characters in connection name. 

Pad. 

Connection name encoded in UNICODE. 

The implementation defined attribute. 

Format number. 

Attribute size in bytes. 

Attribute data. Padded to an even number of bytes. 


Proxy Device identification. 
Vendor Id 

Product Type 

Product Code 

Major Revision 


Minor Revision 


5-42.4.2 Set_Attribute_All (Service Code 0x02) 


This service shall write all attributes associated with an existing instance and shall return the 


following error 
General Status 


0x04 
0x05 
0x08 
0x0C 


codes: 


Extended 


Status 
None 


None 
None 


None 


Error Description 


path syntax error 
Instance undefined 
Unimplemented service 


Wrong object state 


The structure of the Set_Attribute All response is shown in the table below. 


Name 
Connection Flags 


Target Device Id 


Data Type Description 


WORD 
Struct of 
UINT 
UINT 
UINT 
USINT 
USINT 


Connection flags. 

Target Device identification. 
Vendor Id 

Product Type 

Product Code 

Major Revision 


Minor Revision 
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Name Data Type Description 
CS Data Index UDINT ControlNet Scheduling object read data connection_index number. The 
Number default value used when this attribute is not supported shall be 
OxFFFFFFFF. 
Net Connection Network connection parameters for both O>T and T>O0 directions. 
Parameters re is 
USINT The connection time-out multiplier. 
BYTE Transport class and trigger. 
UDINT OST RPI. 
UINT OST network connection parameters. 
UDINT T>0 RPI. 
UINT T=0 network connection parameters. 
Connection Path Struct of The connection path. 
USINT Size of connection path, in 16-bit words, used in the Connection Manager 
Forward Open request service 
USINT reserved. shall be zero. 
Array of The connection path. The open connection path size is the length of this 
UINT array. 
Config #1 Data Struct of Config #1 data. This data is sent to devices via the Connection Manager 
Forward Open request service 
UINT Module configuration data length in bytes. 
Array of Module configuration data. Padded to even number of bytes. 
USINT 
Config #2 Data Struct of Config #2 data. This data is sent to devices via the Connection Manager 
Forward Open request service 
UINT Module configuration data length in bytes. 
Array of Module configuration data. Padded to even number of bytes. 
USINT 
Connection Name The connection name. 
USINT Number of characters in connection name. 
USINT Pad. 
STRING2 | Connection name encoded in UNICODE. 
Implementation The implementation defined attribute. 
Deane atu UINT Format number. 
UINT Attribute size in bytes. 
Array of Attribute data. Padded to an even number of bytes. 
USINT 
Proxy Device Id Proxy Device identification. 
UINT Vendor Id 
UINT Product Type 
UINT Product Code 
USINT Major Revision 
USINT Minor Revision 
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5-42.4.3 


5-42.4.4 


5-42.4.5 


5-284 


Create (Service Code 0x08) 


This service creates a new instance of a Connection Configuration object. Initial attribute 
values may also be specified with this service. The created instance number is assigned by the 
class and returned to the requestor. The following request parameters are defined for this 
service: 


Parameter Data Type Description 
Connection Flags | WORD Connection flags 


NumConnParams | UINT Number of attribute/value pairs that follow. 


> 
5 
fab) 
Ke 
fo) 
So 


ConnParams List of attribute number/value pairs 


Struct of 


Attribute number 


gig 
Z| Zz 
4H} 


Attribute value 


This service shall support the following error codes: 


General Error Description 
Status Status 
0x02 Insufficient resource — maximum number of instances already exist 
Insufficient resource — not enough memory on device 
0x03 Invalid parameter error (when attribute count is invalid) 
0x04 path syntax error 
0x0C Wrong object state 
Ox0E Attempt to set a read-only attribute 
0x13 Insufficient request data — request was too short or truncated 
Ox1C None Attribute list shortage — required attribute was missing 


Delete (Service Code 0x09) 


This service deletes existing connection instances. If addressed to the class-level, all 
connection instances are deleted. If addressed to the instance-level, only the addressed instance 
is deleted. This service shall support the following error codes: 


General Status Extended Error Description 
Status 


0x04 path syntax error 

0x05 Instance undefined 
0x08 Unimplemented service 
0x0C Wrong object state 


Restore (Service Code 0x15) 


This service shall discard modifications to instances that have not yet been committed by the 
Change Complete service. If the Restore service is addressed to the class (instance 0), then 
pending modifications for all instances shall be discarded. If addressed to a specific instance, 
only modifications for that instance shall be discarded. 
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5-42.4.6 


5-42.4.7 


5-42.4.8 
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This service shall support the following error codes: 


General Status Extended Error Description 
Status 


0x04 path syntax error 
0x05 Instance undefined 
0x0C Wrong object state 


Kick Timer (Service Code 0x4B) 


This service shall reinitialize the edit watchdog timer. Upon successful execution of the 
Change _ Start service, the edit watchdog timer shall be started with a period of 60 seconds. 
This timer is used to recover from the loss of a configuration client between the Change_Start 
and Change Complete/Restore operations. Receipt of any service request shall reset the edit 
watchdog timer. Clients may request this service to reset the timer without otherwise effecting 
the state of the Connection Configuration object. If the edit watchdog timer expires, all 
pending modifications shall be discarded. 


This service shall support the following error codes: 


General Status Extended Error Description 
Status 


0x04 path syntax error 


0x05 None Instance undefined 


Open (Service Code 0x4C) 


The Open service shall cause the connection associated with an instance of the Connection 
Configuration object to open. If the Open service is addressed to the class (instance 0), then all 
connection instances shall be opened. If addressed to a specific instance, then only that 
connection instance shall be opened. 


This service shall support the following error codes: 


General Status Extended Error Description 
Status 


0x04 path syntax error 
0x05 Instance undefined 
0x08 Unimplemented service 


Close (Service Code 0x4D) 


The Close service shall cause the connection associated with an instance of the Connection 
Configuration object to close. If the Close service is addressed to the class (instance 0), then all 
connection instances shall be closed. If addressed to the instance level, then only the specified 
instance shall be closed. The Close service shall initiate a “graceful” connection shutdown, 
that is, a Forward_Close request shall be sent to the connection target. Once a connection has 
been closed by this service it shall remain closed until an Open service is issued. 


This service shall support the following error codes: 


General Status Extended Error Description 
Status 


0x04 path syntax error 
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5-42.4.10 
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General Status Extended Error Description 
Status 


0x05 None Instance undefined 


0x08 None Unimplemented service 


Stop (Service Code 0x4E) 


The Stop Connection service shall cause the connection associated with an instance of the 
Connection Configuration object to stop producing data immediately without sending an 
Forward Close request to the connection target. If the Stop Connection service is addressed to 
the class (instance 0), then all connection instances shall be stopped. If addressed to the 
instance level, then the specified instance shall be stopped. Once a connection has been 
stopped, it remains stopped until a subsequent Open service request is issued. 


This service shall support the following error codes: 


General Status Extended Error Description 
Status 


0x04 path syntax error 
0x05 Instance undefined 
0x08 Unimplemented service 


Change_Start (Service Code 0x4F) 


This service shall: 


signal the beginning of an edit session; 
synchronise the current and pending attributes; 
place all connections in the "changeable" state; 
start the edit watchdog timer. 


Change _ Start shall be requested prior to performing any services that modify the attributes of a 
connection. This service shall only be addressed to the class-level (instance 0). 


This service shall support the following error codes: 


General Status Extended Error Description 
Status 


0x04 path syntax error 
0x0C Wrong object state 
0x10 Device state conflict 


Get_Status (Service Code 0x50) 


The Get_Status service shall retrieve the status attribute (attribute 1) for multiple connections 
via a single transaction. This service shall be supported at the class-level (instance 0) only. 
Given a starting instance number, the Get_Status service shall return instance/status pairs until 
either the response buffer is full or the status of all connections has been returned. 


The following request parameter is defined: 


Parameter Data Type Description 


Starting Instance UDINT Starting instance number 
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The following response parameters are defined for this service: 


Parameter Data Type Description 


Done Indicator UINT 0 = More status to be retrieved 
1 = All connection status information has been retrieved. 
All other values reserved. 


NumStatusEntries | UINT Number of instance/status pairs that follow. 
StatusEntries Array of List of instance/status pairs 
Struct of 


i 


DINT Connection Configuration instance number 


USINT General status 
USINT Reserved, shall be 0 
UINT Extended status 


This service shall support the following error codes: 


General Extended Error Description 
Status Status 
0x03 None Invalid parameter error (when attribute count is invalid) 
0x04 None path syntax error 


0x08 None Unimplemented service 


Change_Complete (Service Code 0x51) 


This service shall signal the completion of an edit session. Pending attributes for all modified 
connection instances shall be applied. This service shall take a parameter indicating the type of 
change being performed; either full or incremental. If an incremental edit is specified, then only 
the connections that have been modified shall be broken and re-established. Ifa full edit is 
specified, then all connections shall be broken and all supporting resources shall be freed and 
reallocated before attempting to re-establish the connections. The Change Complete service 
shall be supported at the class-level (instance 0) only. 


The following request parameter is defined: 


Parameter Data Type Description 


Change Type 0= Full 
1 = Incremental 
All other values reserved. 


This service shall support the following error codes: 


General Extended Error Description 
Status Status 
0x02 None Resource unavailable. Indicates that there is not enough memory on the host 


device to support the specified configuration. 
0x04 None path syntax error 


0x0C None Wrong object state 


0x10 None Device state conflict 
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5-42.4.13 Audit Changes (Service Code 0x52) 


This service shall verify whether or not there is enough memory on the host device to support a 
proposed configuration. Like the Change Complete service, this service shall take a parameter 
indicating the type of change being performed; either full or incremental. The Audit_Changes 
service shall be supported at the class-level (instance 0) only. This service allows a 
configuration client to determine if all pending changes will be successful before actually 
committing the changes with the Change Complete service. 


The following request parameter is defined: 


Parameter Data Type Description 


Change Type 0= Full 
1 = Incremental 
All other values reserved. 


This service shall support the following error codes: 


General Extended Error Description 
Status Status 


0x02 None Resource unavailable. Indicates that there is not enough memory on the host 
device to support the specified configuration. 


0x04 None path syntax error 
0x0C None Wrong object state 


0x10 None Device state conflict 
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5-42.5. Behavior 


The flowchart below summarizes the process of creating, editing, and deleting connections. 


Figure 5-42.3. Connection Configuration Object Edit Flowchart 
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INTRODUCTION 


To provide interoperability and promote interchangeability by like device types, there must be 
some consistency between devices of the same type. That is, there must be a core “standard” 
for each device type. In general, like devices must: 


e exhibit the same behavior 
e produce and/or consume the same basic set of I/O data 
e contain the same basic set of configurable attributes 


The formal definition of this information is known as a device profile. This chapter provides a 
detailed definition of a device profile and describes its components. 


A device profile shall contain: 


e an object model for the device type 


e the I/O data format for the device typeconfiguration data and the public interface(s) to 
that data 


You may adopt or extend one of the existing profiles in this chapter or you may define your 
own profile based on the format contained in this chapter. 
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6-2. 


THE OBJECT MODEL 


To provide interoperability among like devices, the same object implemented in two or more 
devices shall behave identically from device to device. Consequently, each object specification 
includes a rigid definition of behavior. 


Every CIP product contains several objects. These objects interact to provide basic product 
behavior. Because the behavior of individual objects is fixed, the behavior of identical 
groupings of objects is also fixed. Therefore, the same group of objects arranged in a specified 
order will interact to produce the same behavior from device to device. 

The grouping of objects used in a device is referred to as that device’s object model. See Figure 
6-2.1. For like devices to produce identical behavior, they must have identical object models. 


Therefore, an object model is included with every device profile to provide for interoperability 
among like CIP devices. 


Figure 6-2.1. Object Model 


Application ) 


Object(s) 


— Identity Object 
Assembly Nees 


Object Router 
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DeviceNet 
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DeviceNet Network 
An object model specification: 


e Identifies all object classes present in the device (required ,optional and conditional). 

e Indicates the number of instances present in each object class. If the device supports 
the dynamic creation and deletion of instances, then the object model states the 
maximum number of instances that can exist within the object class. 
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e States whether or not the object affects behavior of the device. If it does affect 
behavior, the object model states how. 


e Defines the interface to each object. This defines how objects and object classes are 
linked. 


All Objects Present in a Device 


Every device can contain both required objects, optional, and conditional objects. When an 
object is identified as “required,” it is required for all devices of that type. Each device profile 
shall contains an Object Interface Table, which shall list the interface to each object. At a 
minimum, every object model for a CIP common device must specify instances of these object 
classes: 


Connection Object Class or Connection Manager Object Class 

Network specific link object (eg. DeviceNet, ControlNet, TCP/IP Object Class) 
Identity Object Class 

Message Router Object Class 


Although not an object, each device shall also support the Unconnected Message Manager 
(UCMM). In addition to these minimum object classes, object models can, and probably will, 
contain application—specific object classes that are required by the device type. 


Some object classes may be included that provide functions beyond the minimum required of a 
particular device type or that have no effect on device behavior. These types of objects are 
identified in the profile as “optional” or “conditional.” When an object is identified as 
“optional,” it is optional for all devices of that type. The device type dictates what objects are 
necessary to provide the device’s required basic function. When an object is identified as 
“conditional,” it is required “if” a specified condition exists. The Device Profile shall specify 
the conditions. 


Important: Instances of OPTIONAL object classes may provide behavior beyond the behavior 
defined for the device type. At power up, however, this additional behavior 

shall default in a manner such that the device’s behavior appears to be identical to the basic 
behavior defined for that device type. 


Object classes are specified as Object classes are specified as 
REQUIRED when they OPTIONAL when they 
affect in any way the basic behavior specified for | provide behavior beyond the minimum specified 
the device type for the device type 


are used to define the I/O data format of the device | provide functions beyond the minimum required of 
a particular device type or have NO effect on 
behavior of the device 


provide the primary method of access to the provide an optional method of access to the 
device’s configuration data device’s configuration data. 
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6-2.2. Objects That Affect Behavior 


After all objects included in the device are identified, this section of a profile distinguishes 
between objects that do and do not affect the behavior of the device. If an object affects 
behavior, this section states how. Any component (object, attribute, or service) that affects the 
behavior of a device is specified here. The following table shows the format of this part of the 
device profile description. 


Table 6-2.2. Components That Affect Behavior of the Device 


Component Effect on behavior 


Attribute/Object 


6-2.3. Object Interfaces 


The final portion of the object model specification within a device profile is the definition of all 
interfaces to each of the device’s internal objects. Defining object interfaces indicates how the 
objects within a device are connected. 


Behavior 


As you can see in the Flow Transmitter example in Figure 6.2., the objects in this device have 
the following interfaces: 


Table 6-2.3. Flow Transmitter Example: Object Interfaces 


Object Interface 


Name of Object Name of Interface (Explicit Messaging Connection 


Instance, Message Router, I/O connection) 


In summary, an object model defines behavior of a device in the following terms: 


e objects present in device 

e maximum number of object instances 
e how objects affect behavior 

e object interfaces 
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1/0 DATA FORMAT 


This section of a profile defines how a device communicates on the CIP network, which 
includes an exact specification of the device’s I/O data format. 


Smart networked devices can (and probably will) produce and/or consume more than one I/O 
value. Typically, they will produce and/or consume one or more I/O values, as well as status 
and diagnostic information. Each piece of data communicated by a device is represented by an 
attribute of one of the device’s internal objects. 


Communicating multiple pieces of data (attributes) across a single I/O connection requires that 
the attributes be grouped or assembled together into a single data block. Instances of the 
Assembly Object Class perform this grouping. Thus, the definition of a device’s I/O data 
format is equivalent to the definition of the assembly instances used to group the device’s I/O 
data. 


In a device profile, the I/O data format of devices adheres to these guidelines: 


e 1/O Assemblies are either Input type or Output type 
e A device may contain more than one I/O assembly (data format of I/O instances may be 
a configurable option of your device) 


The definition of a device’s I/O assembly instances: 


e Identifies the I/O assembly by instance number, type, and name 
e Specifies the I/O assembly Data attribute format 
e Maps the I/O assembly Data attribute components to other attributes 


I/O Assembly Instances 


Because CIP products can contain one or more I/O assemblies (of either Input type or Output 
type), assembly instances are clearly identified for each device type. The following table 
identifies the I/O assembly instance supported by the example Flow Transmitter device. 


Table 6-3.1. Flow Transmitter Example: Identifying I/O Assembly Instances 


Format of I/O Assembly Data Attribute 


Any device communicating I/O data to and from another device must have knowledge of the 
other device’s I/O data format. The Data attribute of the Assembly Object (instance attribute 
#3) holds this I/O format. Therefore, this section of a profile specifies the format of the Data 
attribute for each assembly instance listed in the assembly instance identification table. 


The Data attribute is an array of bytes. The device profile specifies how that array is defined to 
represent a device’s I/O data. See Table 2.D $$. 


Specification of the I/O assembly Data attribute format adheres to these guidelines: 


e List Data components that are larger than one byte in size with the low-order byte first 
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e Right justify within a byte (starting with bit 0) Data components that are smaller than 
one byte 


e Explicitly state if bits or bytes are to be reserved 


6-3.3. Map of I/O Assembly Data Attribute Components 


Because components of the Assembly Object’s Data attribute are attributes of other objects, a 
device profile contains a mapping of those attributes to their respective objects. 


The map includes specification of the member path (Class ID, Instance ID, etc.) for each data 
component. Specification of the relative addresses of each Data attribute component is 
essentially equivalent to specification of the Member_List instance attribute (#2) of the 
Assembly Object. 


The following table shows the format for an I/O assembly Data attribute mapping. 


Table 6-3.2. Flow Transmitter Example: I/O Assembly Data Attribute Mapping 


Data Component Class Instance Attribute Data Type 
Name Number 
| Name | Name__| 


Component name | Component class XXhex Component 
within profile name within attribute name 
object library within object 
library 


If a device has more than one I/O assembly instance, the profile should include a table similar 
to the one above for each I/O assembly instance. 
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DEVICE CONFIGURATION 


In addition to a product’s object model and format of its I/O data, a device profile includes 
specification of the device’s configurable parameters and the public interface to those 
parameters. 


The configurable parameters in a device directly affect its behavior. Because like devices must 
behave in an identical fashion, they must have identical configuration parameters. 


Important: “Identical configuration” refers to basic configuration. A device may have 
extended functionality (with associated parameters) that is beyond the behavior defined for the 
device type. At power up, this functionality must default in a manner such that the device’s 
behavior appears to be identical to the behavior defined for that device type. 


In addition to defining identical configuration parameters, the public interfaces to those 
parameters must be identical. 


Definition of a device’s configuration includes the following information for each configurable 
attribute: 


e configuration parameter data: 


e all attribute values of each Parameter Object Instance 
e all values in the parameter section of an Electronic Data Sheet 


e at minimum, the following printed data sheet information: 
- parameter name 
- attribute path (class, instance, attribute) 
- data type 
- parameter units 
- minimum/maximum default values 


e effect of parameters on device behavior 


e parameter groups if any configurable parameters are grouped using an instance of the 
Parameter Group Object Class 


e public interface to the device’s configuration (i.e., bulk configuration via a 
configuration assembly, full/stub instances of the Parameter Object Class, etc.) 


Parameter Data 
The definition of each configuration parameter includes specification of one of the following: 


e the instance attributes of an instance of the Parameter Object Class (for each of your 
configuration parameters) 

e all data outlined in the parameter section of an EDS 

e at minimum, the following printed data sheet information: 


parameter name 

attribute path (class, instance, attribute) 
data type 

parameter units 

minimum/maximum default values 
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6-4.2. Effect of Configuration Parameters on Behavior 


The effect that each of the configuration parameters has on the device’s behavior is also 
documented in the configuration section of a device profile. The following table shall be used 
within the device profile. 


Parameter Effect on Behavior 


Parameter name Effect 


6-4.3. Parameter Groups 


If any configurable parameters are grouped using an instance of the Parameter Group Object 
Class, then the definition of each group is specified in this section. 


The definition of each configuration parameter group includes specification of either: 


e _ the instance attributes of an instance of the Parameter Group Object Class (for each of 
your configuration parameters); or 


e all data outlined in the parameter group section of an EDS 


6-4.4. Public Interfaces to Device Configuration Data 


The final portion of the configuration section of a profile clearly specifies the public 
interface(s) to a device’s configuration data. 


6-4.4.1. Parameter Object 


If a device employs instances of the Parameter Object Class, each instance and the 
configuration parameter associated with it is specified here. Also included here is a map of the 
configuration parameter to the object in which it is contained. 


Table 6-4.1. Parameter Instance Listing 


Instance Number Configuration Parameter Name 


Parameter name 


Table 6-4.2. Configuration Parameter Mapping 


Configuration Class Instance Attribute Data Type 
Parameter Name Number 


6-4.4.2. Configuration Assembly Object 


Documentation of a device’s configuration assembly provides information similar to that which 
is specified for the device’s I/O assemblies. This section of a profile includes: 


e specification of the configuration assembly Data attribute format 


e mapping of each configurable attribute using its logical address 
(Class/Instance/Attribute) 
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Specification of the configuration assembly Data attribute format adheres to these guidelines: 


e List Data components that are larger than one byte in size with the low-order byte first 

e Right justify within a byte (starting with bit 0) Data components that are smaller than 
one byte 

e Explicitly state if bits or bytes are to be reserved 


The table below shows how the format of the Configuration Assembly Object’s Data attribute 
is specified. 


Table 6-4.3. Configuration Assembly Data Attribute Format 


Configuration Parameter 1 


Configuration Parameter 2 


Configuration Parameter 3 


In addition to specification of the device’s configuration assembly Data attribute format, this 
section also includes a mapping of the individual configuration assembly Data attribute 
components to their respective objects. 


The map includes specification of the Class, Instance, and Attribute IDs for each data 
component. Specification of the relative addresses of each Data attribute component is 
essentially equivalent to specification of the Member_List instance attribute (#2) of the 
Assembly Object. The table below shows the format for the configuration assembly Data 
attribute mapping. 


Table 6-4.4. Configuration Assembly Data Attribute Mapping 


Configuration Instance Attribute Data Type 
Parameter Name Number 


Configuration 
Parameter 1 
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6-5. EXTENDED DEVICE PROFILES 


You have the option of adopting existing device profiles and then extending them to 
incorporate any additional behavior your product may exhibit. 


Manufacturers of multiple source products may wish to design a product such that it provides 
the basic behavior defined in the product’s device profile and, in addition, provides extended 
functionality that helps distinguish one product from another. 


Important: The basic device profile definition must not change when extending an existing 
device profile. Also, the added functionality must not make the extended profile incompatible 
with the basic device profile. For these reasons, you must adhere to the following rules when 
extending an existing device profile: 


e All new objects, attributes, and services added to the profile are OPTIONAL. 
Backwards compatibility shall be maintained. 


e At power-up, all new behavior must default such that the device’s behavior appears 
identical to the specified default behavior defined for the device type. 


e The basic I/O format must not change. Extended I/O formats can be provided for by 
adding optional I/O assembly instances. 


e The basic configuration must not change. Extended configuration parameters can be 
provided for by adding optional configuration assembly instances or optional instances 
of the Parameter Object Class. 


e Any additional assembly instances must be defined in the vendor-specific address range. 


Important: Instances of the Assembly Class are divided into address ranges to provide for 
extensions to device profiles. See the Assembly Object definition in the object library. 
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DEVICE PROFILE NUMBERING SCHEME 


The table below reveals the numbering scheme to be used for device profile numbering. The 
table shows that a device profile may be either publicly defined or vendor specific: 


Type 


Vendor Specific 
Reserved by CIP 


Device Profiles 


O0hex - §3hex 
64hex - C7hex 


C8hex - FFhex 
100hex - 2FFhex 


300hex - 4FFhex 


500hex-FFFFhex | 64,256 


While you are highly encouraged to adopt or develop a device profile for your product you 
may be unwilling or unable to do so. For this reason ranges of device type numbers have been 
set aside for Vendor Specific” device profiles. If you choose to use one of these device type 
numbers you are not required to publish a device profile for your product. It is important to 
note, however, that if you do not publish your device’s profile, your customers will not be able 
to find direct replacements for your product and, more importantly, they will not be able to use 
your product as a direct replacement for your competitor’s product. Additionally, even vendor 
specific device profiles are required to support the minimum objects listed in section 6-2.1. 


Chapter 6: Device Profiles 


The remainder of this chapter contains listings of all existing device profiles at the time of 


publication. 
For information about: 
AC Drives 


Barcode Scanner 
Circuit Breaker 
Communications Adapter 


Contactor 


Control Station 
ControlNet Physical Layer 


ControlNet Programmable Logic 
Controller 


DC Drives 


Encoder 
General Purpose Analog I/O 
General Purpose Discrete I/O 


Generic Device 
Human-Machine Interface 
Inductive Proximity Switch 


Limit Switch 
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Go to section: 
6-15 


6-17 
6-25 
6-13 
6-27 
6-23 
6-34 
6-33 


6-15 
6-21 
6-14 
6-12 


6-30 
6-10 


Device Type Number: 


02hex 
Not yet assigned 
Not yet assigned 


0Chex 


IShex 
Not yet assigned 


32hex 
OEhex 


IBhex 
Not yet assigned 
Not yet assigned 


O7hex 
hex 
18hex 
O5hex 
4hex 
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6-14 


For information about: 


Mass Flow Controller 


Message Display 
Motor Overload 


Motor Starter 
Photoelectric Sensor 


Pneumatic Valve(s) 


Position Controller 
Resolver 


Servo Drives 
Soft Start 


Weigh Scale 
Vacuum Pressure Gauge 
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Device Type Number: 
6-31 1Ahex 

Not yet assigned 
6-28 16hex 
6-18 10hex 

Not yet assigned 
6-29 17Thex 

Not yet assigned 


The following device type numbers have been obsoleted. 


Obsoleted Device Type 


Number: 
Ohex 
O8hex 
OAhex 
ODhex 
MThex 
I2hex 
I4hex 
19hex 


Open DeviceNet Vendor Assoc. & ControlNet International 


Previous Profile Assignment: 


Control Station 

Encoder 

General Purpose Analog I/O 
Barcode Scanner 

Weigh Scale 

Message Display 

Servo Drives 


Pneumatic Valve(s) 
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GENERIC DEVICE 
Device Type: O00hex 


The Generic Device type defines a device that does not fit into any of the defined device types. 
Initially, there will probably be many Generic Device type devices, but over time, Open 
DeviceNet Vendor Association, Inc. and ControlNet International Special Interest Groups 
(SIGs) will create a specific device profile for devices with similar functionality. The Generic 
Device type devices are not interchangeable. 


Object Model 


The Object Model in Figure 6-8.1. represents the minimum support in a Generic Device. The 
table below indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Object Class # of Instances 
Identity at least 1 
Message Router 1 
Network Specific Link Object at least 1 


Connection Required at least 1 I/O 
and 1 explicit 
Application at least 1 


The Generic Device profile cannot specify the definition of the Assembly Object or the type of 
application objects necessary for device operation. This portion of the device profile must be 
supplied by the product developer as described in Chapter 2, Contents of a Device Profile. 
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Figure 6-8.1. Object Model for the Generic Device 
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6-8.2. How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Object Effect on behavior 
Identity Supports the Reset service 
Message Router No effect 
Network Specific Link | Configures port attributes (node address, data rate, and BOI) 
Object 
Connection Class Contains the number of logical ports into or out of the device 
Assembly Defines input/output and configuration data format 
Application Defines device operation 


6-8.3. Defining Object Interfaces 
The objects in the Generic Device have the interfaces listed in the following table: 
Object Interface 
Identity Message Router 
Message Router Explicit Messaging Connection Instance 


Network Specific Link | Message Router 


Object 

Connection Class Message Router 

Assembly 1/O Connection or Message Router 
Application Assembly or Message Router 
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LIMIT SWITCH 
Device Type: 04hex 


A limit switch mechanically detects the presence or absence of a physical target object. The 
switch detects an object when a lever or rod makes physical contact with the object. 


Object Model 
The Object Model in Figure 6-9.1. represents a limit switch. The table below indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


The CIP Object Library provides more details about these objects. 


Object Class Optional/Required # of Instances 
Identity Required 1 
Message Router Required 1 
Network Specific Link Object Required 1 
Connection Required 2 (explicit,-I/O) 
Assembly Required 1 
Parameter Optional 1 


Presence Sensing Required 1 
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Figure 6-9.1. Object Model for a Limit Switch 
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6-9.2. How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Object Effect on behavior 
Identity Supports the Reset service 
Message Router No effect 
Network Specific Link | Configures port attributes 
Object 
Connection Contains the number of logical ports into or out of the device 
Assembly Defines I/O data format 
Parameter Provides a public interface to the device’s configuration data 
Presence Sensing Affects Output Value (attribute) 
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6-9.5. 


6-9.6. 


6-9.7. 
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Defining Object Interfaces 


The objects in this device have the interfaces listed in the following table: 


Object Interface 

Identity Message Router 

Message Router Explicit Messaging Connection Instance 

Network Specific Link | Message Router 

Object 

Connection Message Router 

Assembly I/O Connection or Message Router 

Parameter Message Router 

Presence Sensing Message Router, Assembly Object, or Parameter Object 
I/O Assembly Instances 


The following table identifies the I/O assembly instance supported by the limit switch. 


Number Name 


Input Data 


1/O Assembly Data Attribute Format 
The I/O Assembly data attribute has the format shown below. 


Mapping I/O Assembly Data Attribute Components 


Instance 


The following table indicates the I/O assembly Data attribute mapping for this limit switch 


device. 
Class Instance Attribute 
Number 


Data Component 


Name 
Number 


Defining Device Configuration 


Public access to the Presence Sensing Object by the Message Router must be supported for 
configuration of this device type. If supported, the optional Parameter Object may be used to 
access the device type’s configuration parameter. 


Parameter Object Instances 


The limit switch contains one instance of the Parameter Object Class. This instance is a 
Parameter Object stub. See The CIP Object Library for the definition of the Parameter Object 
and an explanation of how it is used for configuration. 
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6-9.8. 


6-20 


The following table identifies the Parameter Object instance supported by the limit switch. 


Number Name 


Operation Mode Configuration 


Mapping Parameter Object Data 


The following table indicates the Parameter Object data mapping for the limit switch device. 


Class Instance Attribute 
Number 
Nabe Naber 


Configuration Parameter Definitions 


Configuration Parameter 
Name 


Operate Mode Configuration 


The following sections of an example EDS show the information necessary to define the 
configure parameters for a limit switch. 


[Parms] 
Param1= $Operate Mode 
0, $Data Placeholder 
2,”20 Oe 24 01 30 08”, $Path size and Path to Operate Mode Attr 
0x0002, $Descriptor (support enumerated strings 
4,1 $Data Type and Size (Boolean) 
”*Operate Mode”, $Name 
ie $Units (not used) 
ee $User Manual Ref (not used) 
0,1,0, $min, max, default values 
0,0,0,0, $mult, div, base, offset scaling (not used) 
0,0,0,0, $mult, div, base, offset links (not used) 
1; $decimal places 
[EnumPar] 
Param1l= $Operate Mode Enumerated Strings 
”Normally Open”, $For value=0 
Normally Closed”; $For value=1 


Effect of Configuration Parameters on Behavior 


The configuration parameter affects the device’s behavior as shown below. 


Parameter Effect on Behavior 


Operate Mode Inverts the level defined for the Output attribute of the Presence Sensing Object 
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INDUCTIVE PROXIMITY SWITCH 
Device Type: O5hex 


An inductive proximity switch operates in an electromagnetic field. When it senses a change in 
the field, it sends a signal to an output amplifier circuit to change the state of the circuit. 


Object Model 


The Object Model in Figure 6-10.1. represents an inductive proximity switch. The table below 
indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


The CIP Object Library provides more details about these objects. 


Object Class Optional/Required # of Instances 
Identity Required 1 
Message Router Required 1 
Network Specific Link Object Required 1 
Connection Required 2 (explicit, I/O) 
Assembly Required 1 


Parameter Optional 1 


Presence Sensing Required 1 
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Figure 6-10.1. Object Model for an Inductive Proximity Switch 
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6-10.2. How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Object Effect on behavior 
Identity Supports the Reset service 
Message Router No effect 
Network Specific Link | Configures port attributes 
Object 
Connection Contains the number of logical ports into or out of the device 
Assembly Defines I/O data format 
Parameter Provides a public interface to the device’s configuration data 
Presence Sensing Effects Output Value (attribute) 


6-10.3. Defining Object Interfaces 


The objects in this device have the interfaces listed in the following table: 


Object Interface 
Identity Message Router 
Message Router Explicit Messaging Connection Instance 
Network Specific Link | Message Router 
Object 
Connection Message Router 
Assembly I/O Connection or Message Router 
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6-10.5. 


6-10.6. 


6-10.7. 
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Parameter Message Router 
Presence Sensing Message Router, Assembly Object, or Parameter Object 
1/O Assembly Instances 


The following table identifies the I/O assembly instance supported by the inductive proximity 
switch. 


Number Name 


Input Data 


1/O Assembly Data Attribute Format 
The I/O Assembly data attribute has the format shown below. 


d d d d d c 


Mapping I/O Assembly Data Attribute Components 


The following table indicates the I/O assembly Data attribute mapping for this inductive 
proximity switch device. 


Class Instance Attribute 
Number 


Number 


Defining Device Configuration 


Data Component 
Name 


Diagnostic 


Public access to the Presence Sensing Object by the Message Router must be supported for 
configuration of this device type. If supported, the optional Parameter Object may be used to 
access the device type’s configuration parameter. 


Parameter Object Instances 
The following table identifies the Parameter Object instance supported by the inductive 
proximity switch. 


Number Name 


Operation Mode Configuration 


Mapping Parameter Object Data 


The following table indicates the Parameter Object data mapping for the inductive proximity 


switch device. 
Class Instance Attribute 
Number 


Name Number Number 
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Configuration Parameter 
Name 


Operate Mode Configuration 
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6-10.7.3. Configuration Parameter Definitions 


The following sections of an example EDS show the information necessary to define the 
configuration parameters for an inductive proximity switch. 


[Parms] 
Param 1= $Operate Mode 
0, $Data Placeholder 
3,”20 Oe 24 01 30 08”, $Path size and Path to Operate Mode Attr 
0x0002, $Descriptor (support enumerated strings) 
4,1 $Data Type and Size (Boolean) 
”*Operate Mode”, $Name 
ie $Units (not used) 
aoe $User Manual Ref (not used) 
0,1,0, $min, max, default values 
0,0,0,0, $mult, div, base, offset scaling (not used) 
0,0,0,0, $mult, div, base, offset links (not used) 
1; $decimal places 
[EnumPar] 
Paraml= $Operate Mode Enumerated Strings 
*Normally Open”, $For value=0 
Normally Closed”; $For value=1 


6-10.8. Effect of Configuration Parameters on Behavior 


The configuration parameter affects the device’s behavior as shown below. 


Parameter Effect on Behavior 


Operate Mode Inverts the level defined for the Output attribute of the 


Presence Sensing Object 
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6-11. PHOTOELECTRIC SENSOR 
Device Type: 06hex 


A photoelectric sensor electrically senses the presence or absence of a target object or part of a 
machine. Typical applications include assembly, packaging, and material handling. 
6-11.1. Object Model 


The Object Model in Figure 6-11.1. represents a photoelectric sensor. The table below 
indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


The CIP Object Library provides more details about these objects. 


Object Class # of Instances 
Identity 
Message Router 1 
Network Specific Link Object 1 
Connection 2 (explicit, I/O) 
Assembly 
Parameter 1 
Presence Sensing 1 


Figure 6-11.1. Object Model for a Photoelectric Sensor 
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6-11.2. How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Object Effect on behavior 
Identity Supports the Reset service 
Message Router No effect 
Network Specific Link | Configures port attributes 
Object 
Connection Contains the number of logical ports into or out of the device 
Assembly Defines I/O data format 
Parameter Provides a public interface to the device’s configuration data 
Presence Sensing Affects output value 


6-11.3. Defining Object Interfaces 


The objects in this device have the interfaces listed in the following table: 


Object Interface 
Identity Message Router 
Message Router Explicit Messaging Connection Instance 
Network Specific Link | Message Router 
Object 
Connection Message Router 
Assembly I/O Connection or Message Router 
Parameter Message Router 
Presence Sensing Message Router, Assembly Object, or Parameter Object 


6-11.4. I/O Assembly Instances 
The following table identifies the I/O assembly instance supported by the photoelectric sensor. 


Name 


Input Data 


6-11.5. I/O Assembly Data Attribute Format 
The I/O Assembly data attribute has the format shown below. 


d d d d d c 


6-11.6. Mapping I/O Assembly Data Attribute Components 


The following table indicates the I/O assembly Data attribute mapping for this photoelectric 
sensor device. 


Data Component Class Instance Attribute 
Name Number 
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6-11.7.. Defining Device Configuration 


Public access to the Presence-Sensing Object by the Message Router must be supported for 
configuration of this device type. If supported, the optional Parameter Object may be used to 
access the device type’s configuration parameter. 


6-11.7.1. Parameter Object Instances 


The photoelectric sensor contains one instance of the Parameter Object Class. This instance is a 
Parameter Object stub. See Chapter 5, The CIP Object Library, for the definition of the 
Parameter Object and an explanation of how it is used for configuration. 


The following table identifies the Parameter Object instance supported by the photoelectric 
sensor. 


Number Name 


Operation Mode Configuration 


6-11.7.2. Mapping Parameter Object Data 


The following table indicates the Parameter Object data mapping for the photoelectric sensor 
device. 


Configuration Parameter 
Name 


Class Instance Attribute 
Number 


6-11.7.3. Configuration Parameter Definitions 


Number 


Operate Mode Configuration 


The following sections of an example EDS show the information necessary to define the 
configuration parameters for photoelectric sensor. 


[Parms] 

Param 1= $Operate Mode 
0, $Data Placeholder 
2,”20 Oe 24 01 30 08”, $Path size and Path to Operate Mode Attr 
0x0002, $Descriptor (support enumerated strings 
4,1 $Data Type and Size (Boolean) 
”*Operate Mode”, $Name 
cae $Units (not used) 
ae $User Manual Ref (not used) 
0,1,0, $min, max, default values 
0,0,0,0, $mult, div, base, offset scaling (not used) 
0,0,0,0, $mult, div, base, offset links (not used) 
1; $decimal places 
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[EnumPar] 
Param1l= $Operate Mode Enumerated Strings 
*Light Operate”, $For value=0 
Dark Operate”; $For value=1 


6-11.8. Effect of Configuration Parameters on Behavior 


The configuration parameter effects the device’s behavior as shown below. 


Parameter Effect on Behavior 


Operate Mode Inverts the level defined for the Output attribute of the 


Presence Sensing Object 
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6-12. 


6-12.1. 


Release 1.0 


GENERAL PURPOSE DISCRETE I/O 
Device Type: 07hex 


A General Purpose Discrete I/O device type interfaces to multiple discrete I/O device types that 
do not have network capabilities. Examples include sensors and actuators. 


Object Model 


The Object Model in Figure 6-12.1. represents a General Purpose Discrete I/O device. The 
table below indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


The CIP Object Library provides more details about these objects. 


Object Class Optional/Required # of Instances 
Identity Required 1 
Message Router Required 1 
Network Specific Link Object Required 1 
Connection Required 1 
Assembly Required * 
Discrete Input Group Optional 1 


Discrete Output Group Optional 1 


* 
* 
* 


Discrete Input Point 


* 
* 
* 
* 


Discrete Output Point 
* Depends on the level of I/O support provided by the product. 


** Required for input functions 
*** Required for output functions 
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Figure 6-12.1. Object Model for a General Purpose Discrete I/O Device 
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6-12.2. 


6-12.3. 


6-12.4. 


Release 1.0 


How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Object Effect on behavior 
Identity Supports the Reset service 
Message Router No effect 
Network Specific Link | Configures port attributes 
Object 
Connection Contains the number of logical ports into or out of the device 
Assembly Defines I/O data format and Output Configuration data format 
Discrete Input Point Defines behavior of the discrete input points for this device 
Discrete Input Group Stores the combined status of the Discrete Input Points 


Discrete Output Point Defines the behavior of discrete output points for this device 


Discrete Output Group | Defines the Idle and Fault actions of the discrete output points 


Defin 


ing Object Interfaces 


The objects in this device have the interfaces listed in the following table: 


Object Interface 
Identity Message Router 
Message Router Explicit Messaging Connection Instance 
Network Specific Link | Message Router 
Object 
Connection Message Router 
Assembly 1/O Connection or Message Router 
Discrete Input Group Message Router 


Discrete Output Group | Message Router 


Discrete Input Point Message Router 


Discrete Output Point Message Router or Assembly Object 


1/O Assembly Instances 


The General Purpose Discrete I/O device I/O assemblies consist of: 


six predefined input assemblies with single input status bits 

one product-specific input assembly with a single input status bit 

six predefined input assemblies with multiple input status bits 

one product-specific input assembly with multiple input status bits 

six predefined output assemblies 

one product-specific output assembly 

six predefined input assemblies with output status bits 

one product-specific output status assembly 

four input assemblies with multiple input status bits and multiple output status bits 
nine input assemblies with a single input status bit and multiple output status bits 
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The following table identifies the I/O assembly instances supported by this device. 


Number Type Name 


Input 1-Point Input with No Status Bit 
Input 2-Point Input with No Status Bit 
Input 4-Point Input with No Status Bit 
Input 8-Point Input with No Status Bit 
Input 16-Point Input with No Status Bit 


Input 32-Point Input with No Status Bit 


NLD] MTR] wl] nNn]r 


N 
& 


Input N-Point Input with No Status Bit 


11 Input 1-Point Input with Single Status Bits 
12 Input 2-Point Input with Single Status Bit 
13 Input 4-Point Input with Single Status Bit 
14 Input 8-Point Input with Single Status Bit 
15 Input 16-Point Input with Single Status Bit 
16 Input 32-Point Input with Single Status Bit 
17 Input N-Point Input with Single Status Bit 


21 Input 1-Point Input with Multiple Status Bits 
22 Input 2-Point Input with Multiple Status Bits 
23 Input 4-Point Input with Multiple Status Bits 
Input 8-Point Input with Multiple Status Bits 
25 Input 16-Point Input with Multiple Status Bits 
26 Input 32-Point Input with Multiple Status Bits 
27 Input N-Point Input with Multiple Status Bits 


31 Output 1-Point Output 
32 Output 2-Point Output 
33 Output 4-Point Output 
34 Output 8-Point Output 
35 Output 16-Point Output 
36 Output 32-Point Output 
37 Output N-Point Output 


41 Input 1-Point Output Status Bit 
42 Input 2-Point Output Status Bits 
43 Input 4-Point Output Status Bits 
44 Input 8-Point Output Status Bits 
45 Input 16-Point Output Status Bits 
46 Input 32-Point Output Status Bits 
47 Input N-Point Output Status Bits 


52 Input 2-Point Input with Single Input Status and Single Output 
Status Bits 
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6-12.5. 


Release 1.0 


53 


54 


55 


56 


57 


62 


63 


64 


65 


70 


71 


72 


73 


74 


75 


76 


77 


78 


Number 
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Type Name 
Input 4-Point Input with Single Input Status and Single Output 
Status Bits 


Input 8-Point Input with Single Input Status and Single Output 
Status Bits 


Input 16-Point Input with Single Input Status and Single Output 
Status Bits 


Input 32-Point Input with Single Input Status and Single Output 
Status Bits 


Input N-Point Input with Single Input Status and Single Output 
Status Bits 


2-Point Input with Multiple Input Status and Multiple 
Output Status Bits 


4-Point Input with Multiple Input Status and Multiple 
Output Status Bits 


8-Point Input with Multiple Input Status and Multiple 
Output Status Bits 


16-Point Input with Multiple Input Status and Multiple 
Output Status Bits 


Input 1-Point Input with Single Input Status and 1 Output 
Status Bit 

Input 2-Point Input with Single Input Status and 1 Output 
Status Bit 

Input 2-Point Input with Single Input Status and 2 Output 


Status Bits 


Input 4-Point Input with Single Input Status and 2 Output 
Status Bits 


Input 4-Point Input with Single Input Status and 4 Output 
Status Bits 


8-Point Input with Single Input Status and 4 Output 
Status Bits 


8-Point Input with Single Input Status and 8 Output 
Status Bits 


16-Point Input with Single Input Status and 8 Output 
Status Bits 


16-Point Input with Single Input Status and 16 Output 
Status Bits 


I/O Assembly Data Attribute Format 


The I/O Assembly data attribute for the input data with no status bit has the format shown 
below. 
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1 Reserved Discrete 
Input 1 


2 Reserved Discrete Discrete 
Input2 Input 1 

3 Reserved Discrete | Discrete | Discrete Discrete 
Input4 Input3 Input2 Input 1 

4 Discrete |Discrete | Discrete | Discrete |Discrete | Discrete | Discrete Discrete 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input 1 

5 Discrete |Discrete | Discrete | Discrete |Discrete | Discrete | Discrete Discrete 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input 1 

1 Discrete |Discrete | Discrete | Discrete |Discrete | Discrete | Discrete Discrete 
Inputl6 = |InputlS |Inputl4 |Inputl3 |Inputl2 | Inputll | Inputl0d Input9 

6 Discrete |Discrete | Discrete | Discrete |Discrete | Discrete | Discrete Discrete 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input 1 

1 Discrete |Discrete | Discrete | Discrete |Discrete | Discrete | Discrete Discrete 
Inputl6 = |InputlS | Inputl4 |Inputl3 |Inputl2 | Inputll | Inputl0d Input9 

2 Discrete |Discrete | Discrete | Discrete |Discrete | Discrete | Discrete Discrete 

Input24 |Input23) | Input22 |Input21 |Input20 | Inputl9 = | Inputl8 Input17 
Discrete |Discrete | Discrete | Discrete |Discrete | Discrete | Discrete Discrete 
Input32 |Input31 | Input30 | Input29 |Input28 | Input27 | Input26 Input25 

Discrete |Discrete | Discrete | Discrete |Discrete | Discrete | Discrete Discrete 

Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input 1 


reserved Discrete 1 Discrete 
Input Input 
N N-2 


The I/O Assembly data attribute for the input data with one status bit has the format shown 
below. 


ie ea 


Instance Byte Bit Bit7 | Bit | Bits | Bit | pits | pita | 4 Bit | Bits | | Bit2 | 2 | Bier | 1 Bit 0 


1 Status Reserved Discrete 
Input 1 

12 Status Reserved Discrete Discrete 
Input2 Input 1 

13 | [eae Discrete | Discrete | Discrete Discrete 
[cee Input3 Input2 Input 1 

14 = Discrete | Discrete | Discrete |Discrete | Discrete | Discrete Discrete 
7s Input7 Input6 Input5 Input4 Input3 Input2 Input 1 


Sea || Beene 


15 | Discrete | Discrete | Discrete |Discrete | Discrete | Discrete Discrete 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input 1 


Discrete Discrete | Discrete | Discrete | Discrete Discrete 
Input16 Inputl4 | Inputl3 |Inputl2 | Inputl1 Input9 
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Status Reserved 


16 Discrete i Discrete | Discrete | Discrete | Discrete i Discrete 
Input8 Input6 Input5 Input4 Input3 Inputl 
Discrete i Discrete | Discrete | Discrete | Discrete i Discrete 
Input16 Inputl4 | Inputl3 |Inputl2 | Inputl1 Input9 
Discrete i Discrete | Discrete | Discrete | Discrete i Discrete 
Input24 Input22 |Input21 |Input20 = | Inputl9 Input17 
Discrete i Discrete | Discrete | Discrete | Discrete i Discrete 
Input32 Input30 | Input29 | Input28 | Input27 Input25 

17 Discrete i Discrete | Discrete | Discrete | Discrete i Discrete 


Input8 Input6 Input5 Input4 Input3 Inputl 


Status Reserved Discrete i Discrete 
Input -1 | Input 
N N-2 


The I/O Assembly data attribute for the input data with multiple status bits has the format 
shown below. 


22, Reserved Status2 Status] Discrete Discrete 
Input2 Input 1 

223 Status4 Status3 Status2 Status] Discrete | Discrete i Discrete 
Input4 Input3 Input 1 


24 i i 1 Discrete | Discrete | Discrete i Discrete 
Input5 Input4 Input3 Input 1 


DS 1 i 1 Discrete | Discrete | Discrete i Discrete 
Input5 Input4 Input3 Input 1 


Discrete i i Discrete | Discrete | Discrete i Discrete 
Input16 Inputl3  |Inputl2 | Inputl1 Input9 


26 Discrete i i Discrete | Discrete | Discrete i Discrete 
Input8 Input5 Input4 Input3 Input 1 
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ine ove [ oer oe [ows [wee [os | or | wr | we 


27 


Discrete Discrete 
Input32 Input25 


Ce 


Cs A a 


Discrete Discrete 


Inputl 


Discrete 
Input3 


Discrete 
Input4 


Discrete 
Input5 


Input8 


M-2 Status5 Status4 Status3 Status2 Status 1 Discrete i Discrete 
a Input 
N-2 
ee es 


M Reserved Status Status Status 
N N-1 N-2 


The I/O Assembly data attribute for the output data has the format shown below. 


Instance 


31 


eB); 


33 


34 


BS 


36 


6-36 


Pave] ar [ove [ows [ae [os [ae [ot | ae 
Reserved Discrete 
Output 1 

Reserved Discrete 
Output4 


Discrete 
Output6 


Discrete 
Output 1 


Discrete 
Output 1 


Discrete 
Output3 


Discrete 
Output 1 


Discrete 
Output3 


Discrete 
Output4 


Discrete 
Output5 


Discrete 
Output 1 


Discrete 
Output2 


Discrete 
Output3 


Discrete 
Output4 


Discrete 
Output5 


Discrete 
Output6 


Discrete 
Output7 


Discrete 
Output9 


Discrete | Discrete | Discrete | Discrete 
Output14 | Outputl3 | Outputl2 | Output]! 


Discrete 
Output 1 


Discrete 
Output3 


Discrete 
Output4 


Discrete 
Output5 


Discrete 
Output6 


Discrete 
Output9 


Discrete | Discrete | Discrete | Discrete 
Output14 | Outputl3 | Outputl2 | Output]! 
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Instance 


av 


3 


reserved 


Discrete 
Output22 


Discrete 
Output30 


Discrete 
Output6 


Discrete 
Output21 


Discrete 
Output29 


Discrete 
Output5 


Discrete 
Output20 


Discrete 
Output28 


Discrete 
Output4 
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Discrete 
Output19 


Discrete 
Output27 


Discrete 
Output3 


Discrete 
Output 
N 


Bit 0 


Discrete 
Output17 


Discrete 
Output25 


Discrete 
Output 1 


Discrete 
Output 
N-2 


The I/O Assembly data attribute for the output data status bits has the format shown below. 


Instance 


41 


42 


43 


44 


45 


46 


2 


Reserved Discrete 
Output 
Status4 


Discrete | Discrete 
Output | Output 
Status8 Status7 


Discrete 
Output 
Status7 


Discrete | Discrete 
Output | Output 
Statusl6 | Status15 


Discrete | Discrete 
Output | Output 
Status8 | Status7 


Discrete | Discrete 
Output | Output 
Statusl16 | Status15 


Discrete | Discrete 
Output | Output 
Status24 | Status23 


Discrete 
Output 
Status22 


Discrete 
Output 
Status5 


Discrete 
Output 
Status 13 


Discrete 
Output 
Status5 


Discrete 
Output 
Status 13 


Discrete 
Output 
Status2 1 


Discrete 
Output 
Status4 


Discrete 
Output 
Status4 


Discrete 
Output 
Status 12 


Discrete 
Output 
Status4 


Discrete 
Output 
Status 12 


Discrete 
Output 
Status20 


Discrete 
Output 
Status 19 
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Discrete 
Output 
Status2 


Discrete 
Output 
Status2 


Discrete 
Output 
Status 10 


Discrete 
Output 
Status2 


Discrete 
Output 
Status 10 


Discrete 
Output 
Status18 


Bit 0 


Discrete 
Output 
Status 1 


Discrete 
Output 
Status 1 


Discrete 
Output 
Status 1 


Discrete 
Output 
Status 1 


Discrete 
Output 
Status 1 


Discrete 
Output 
Status9 


Discrete 
Output 
Status 1 


Discrete 
Output 
Status9 


Discrete 


Output 
Status 17 
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3 


Discrete | Discrete Discrete Discrete Discrete Discrete 
Output | Output Output Output Output Output 
Status32 | Status31 Status29 Status28 Status26 Status25 


Discrete | Discrete Discrete Discrete Discrete Discrete 
Output | Output Output Output Output Output 
Status8 Status7 Status5 Status4 Status2 Status 1 


M Reserved Discrete Discrete 
Output Output 
Status N-1 | Status N-2 


The I/O Assembly data attribute for the input data with one input status bit and one output 
status bit has the format shown below. 


47 


52 Discrete | Discrete Reserved Discrete 
Input Output Inputl 
Status Status 
53 Discrete | Discrete Reserved Discrete Discrete 
Input Output Input4 Inputl 
Status Status 
54 Discrete | Discrete Discrete Discrete 
Input8 Input7 Input4 Input 1 
1 Discrete | Discrete Reserved 
Input Output 
Status Status 
55 Discrete | Discrete Discrete Discrete 
Input8 Input7 Input4 Input 1 
1 Discrete | Discrete Discrete Discrete 
Inputl6 | Input15 Input12 Input9 
2 Discrete | Discrete Reserved 
Input Output 
Status Status 
56 Discrete | Discrete Discrete Discrete 
Input8 Input7 Input4 Input 1 
1 Discrete | Discrete Discrete Discrete 
Inputl6 | Input15 Input12 Input9 
2 Discrete | Discrete Discrete Discrete 
Input24 | Input23 Input20 Input17 
3 Discrete | Discrete Discrete Discrete | Discrete | Discrete Discrete 
Input32 | Input31 Input29 Input28 |Input27 | Input26 Input25 


6-38 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1; CIP Common Specification Chapter 6: Device Profiles 


Release 1.0 


Instance 


Discrete | Reserved 
Output 
Status 


Discrete Discrete Discrete 
Input7 Input4 Input 1 


Discrete Reserved Discrete 
Output Input 
Status N-2 


The I/O Assembly data attribute for the input data with multiple input status bits and multiple 
output status bits has the format shown below. 


62 Reserved Discrete Discrete Discrete 
Output Input Inputl 
Status2 Status2 
63 Discrete | Discrete Discrete Discrete Discrete 
Input Input Input Input4 Input 1 
Status4 Status3 Status 1 
1 Reserved Discrete Discrete Discrete 
Output Output Output 
Status4 Status2 Status 1 
64 Discrete Discrete Discrete 
Input7 Input4 Input 1 
1 Discrete Discrete Discrete Discrete 
Input Input Input Input 
Status7 Sta6tus5 Status4 Status 1 
2, Discrete | Discrete Discrete Discrete Discrete Discrete 
Output | Output Output Output Output Output 
Status8 Status7 Status5 Status4 Status2 Status 1 
65 Discrete | Discrete Discrete | Discrete Discrete | Discrete | Discrete Discrete 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input 1 
1 Discrete | Discrete Discrete | Discrete Discrete | Discrete | Discrete Discrete 
Inputl6 | Input15 Inputl4 = | Input13 Inputl2 |Inputl1 | Inputld Input9 
2) Discrete Discrete Discrete 
Input Input Input 
Status7 Status4 Status 1 
3 Discrete Discrete Discrete Discrete 
Input Input Input Input 
Statusl6 | Status15 Status14 | Status15 Status12 | Statusl1 | Status10 Status9 


4 Discrete | Discrete Discrete Discrete Discrete Discrete 
Output | Output Output Output Output Output 
Status8 Status7 Status5 Status4 Status2 Status 1 
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Discrete | Discrete Discrete Discrete Discrete 
Output | Output Output Output Output 
Statusl6 | Status15 Status14 | Status13 Status12 | Statusl1 | Status10 Status9 


The I/O Assembly data attribute for the input data with single input status bit and multiple 
output status bits has the format shown below. 


70 1 Reserved Discrete | Discrete 
Output Input 1 
Status 1 


71 i Discrete i Discrete 
Output Input 1 
Status 1 


72 i Discrete 1 i Discrete 
Output Input 1 
Status2 


73 i Discrete | Discrete Discrete i i Discrete 
Output | Output Input4 Inputl 
Status2 | Status1 


74 i i 1 Discrete Discrete 1 i Discrete 
Output Input4 Input 1 
Status 1 


75 1 1 1 1 1 1 i Discrete 
Input 1 
Discrete i Discrete Discrete 
Output Output Output 
Status4 Status2 Status 1 


716 1 1 1 1 1 i i Discrete 
Input 1 
Discrete i i Discrete i i Discrete 
Output Output Output 
Status7 Status4 Status 1 


Vi 1 Discrete i i Discrete i i Discrete 
Input4 Input 1 


Discrete i i Discrete i i Discrete 
Input 15 Input12 Input9 


Discrete 1 i Discrete 1 i Discrete 
Output Output Output 
Status7 Status4 Status 1 
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Instance 


Reserved 


Discrete | Discrete Discrete | Discrete Discrete | Discrete | Discrete 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 

1 Discrete | Discrete Discrete | Discrete Discrete | Discrete | Discrete 
Inputl6 | Input15 Inputl4 | Input13 Inputl2 |Inputl1 | Inputld 


3 


Discrete 
Input 1 


Discrete 
Input9 


2 Discrete | Discrete Discrete Discrete Discrete Discrete 
Output | Output Output Output Output Output 
Status8 | Status7 Status5 Status4 Status2 Status 1 
3 Discrete | Discrete Discrete Discrete Discrete Discrete 
Output | Output Output Output Output Output 
Statusl6 | Status15 Status13 Status 12 Status10 Status9 
Reserved 


Mapping I/O Assembly Data Attribute Components 


The following table indicates the I/O assembly Data attribute mapping for the General Purpose 
Discrete I/O device for the input assemblies with a single status bit. 


Class Instance Attribute 
Number 


Important: If I/O Assembly instances 7, 17, 27, 37, 47 or 57 are supported, the “Max 
Instance” attribute at the class level of the Discrete Input Point class or of the Discrete Output 
Point class must be supported. 


Data Component Name 


Discrete InputNV 


Status or Discrete Input Status 


The following table indicates the I/O assembly Data attribute mapping for the General Purpose 
Discrete I/O device for the input assemblies with multiple status bits. 


Class Instance Attribute 
Number 
Nawab 


Data Component Name 


Discrete InputNV 


StatusN or Discrete Input StatusNV 
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6-12.7. 


6-12.7.1. 


6-12.8. 


6-12.9. 


6-12.10. 


6-42 


The following table indicates the I/O assembly Data attribute mapping for the General Purpose 
Discrete I/O device for the output assemblies. 


Class Instance Attribute 
Number 
Number 


Defining Device Configuration 


Data Component Name 


Discrete OutputV 


Discrete Output StatusV 


Discrete Output Status 


Primary public interface to the Input Filter Selection parameter is accessed by the Discrete 
Output Group Object. 


Input Configuration 


There are no configuration parameters defined for the discrete inputs. 


Output Configuration Assembly Instances 


The following table identifies the output configuration assembly instance supported by the 
General Purpose Discrete I/O device. 


40 Output Configuration 


Output Configuration Assembly Data Attribute Format 


The Output Configuration Assembly Data attribute (typical throughout the document) has the 
format shown below. 


40 Reserved |Reserve | Reserve | Reserve | Reserve | Reserve | Idle Fault 
d d d d d Action | Action 


Mapping Output Configuration Assembly Data Attribute Components 


The output configuration is accessed by instances of the Assembly Object Class. The following 
table indicates the output configuration assembly Data attribute mapping for the General 
Purpose Discrete I/O device. 


Instance Attribute 
Number 
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Configuration 
Parameter Name 


Fault Action 


Idle Action 
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The following table shows the effect of the Fault State and Idle State parameters on behavior. 


Parameter Effect on behavior 
Fault Action Indicates whether the Fault Value or the last state is to be placed 
at the output in the event of a fault. All Discrete Outputs in the 
device are set to the same Fault Action. Note: Fault Value can 
not be configured via this assembly. The default is 0. 
Idle Action Indicates whether the Idle Value or the last state is to be placed 


at the output in the event of an idle. All Discrete Outputs in the 
device are set to the same Idle Action. Note: Idle Value can not 
be configured via this assembly. The default is 0. 


The following portion of an example EDS shows the information necessary to define the output 
configuration parameters for the General Purpose Discrete I/O device. 


[Params] 
Param1= $ Fault Action 

0, $ reserved 

6,”20 1E 24 01 30 07”, $ Link Path Size and Link Path 

0x00, $ No support for settable path, 
$ enumerated strings, scaling, 
$ scaling link, or real time 
$ update of value. Value is 
$ gettable and settable. 

4, $ Data Type 

1, $ Data Size 

Fault Action”, $ Parameter Name 

<< $ Units String not used 

is $ Help string not used 

0,1,0; $ Min, Max, and Default values 

1,1,1,0,0,0,0,0,0; $ Not used 

Param2= $ Idle Action 

0, $ reserved 

6,"20 1E 24 01 30 09”, $ Link Path Size and Link Path 

0x00, $ No support for settable path, 
$ enumerated strings, scaling, 
$ scaling link, or real time 
$ update of value. Value is 
$ gettable and settable. 

4, $ Data Type 

1, $ Data Size 

Idle Action”, $ Parameter Name 

baie $ Units String not used 

pe $ Help string not used 

0,1,0; $ Min, Max, and Default values 

1,1,1,0,0,0,0,0,0; $ Not used 

[Groups] $ No need to support 
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6-13. Communications Adapter 


Device Type: 0Chex 


The Communications Adapter device type acts as a gateway from the CIP network to other 
technologies. Traditionally, a gateway connects to foreign networks (for example, RS-232) or 
backplanes (for example, VME). The technologies involved greatly affect the gateway 
modeling and definition. Initially, some devices will be defined as Communications Adapter 
devices, and the ODVA and CI forum may create a specific device profile for devices with 
similar functions. 


6-13.1. Object Model 


The Object Model in Figure 6-13.1. represents the minimum support in a Communications 
Adapter. The table below indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Object Class # of Instances 
Identity at least 1 
Message Router 1 
Network Specific Link Object at least 1 


Connection Required at least 1 I/O 
and | explicit 

Assembly Possibly 1 or more 

Application Possibly 1 or more 


The Communications Adapter profile cannot specify the definition of the Assembly Object or 
the type of application objects necessary for device operation. This portion of the device profile 
must be supplied by the product developer as described in Chapter 2 $$, Contents of a Device 
Profile. Any Assembly instances created must be in the vendor-specific range (64pex - C7hex)- 


Application objects may be public, vendor-specific, or both. 
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Figure 6-13.1. Object Model for the Communications Adapter 
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6-14. GENERAL PURPOSE ANALOG I/O 


The profile for this device type will be defined by the Open DeviceNet Vendor Association, 
Inc. and ControlNet International. 
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6-15. 


6-15.0.1 


6-15.1. 


Release 1.0 


AC DRIVES 
Device Type: 02hex 


DC DRIVES 
Device Type: 13 hex 


These device profiles describe standard objects and behaviour for AC and DC drives including 
Standard Scalar (V/Hz) AC, Vector AC, and DC Drives. 


The functionality of drives covered includes: 


e Open loop speed (frequency) control 
e Closed loop speed (frequency) control 
e Torque control 

e No position control 


These profiles makes the drives inter-operable, but not directly interchangable without doing 
drive configuration through the drive local interface, a network configuration tool or other 
means of configuration outside the CIP interface. 


The AC and DC Drive profiles are part of a “Hierarchy of Motor Control Devices” that is 
supported by CIP. This hierarchy includes: 


e Contactors and Across the Line Motor Starters 
e Soft Starters 

e AC and DC Drives 

e Servo Drives 


Devices within this hierarchy all use a common “Control Supervisor” object to control the state 
behavior of the device. All but the low level Contactors and Across the Line Motor Starters 
also use a common “Motor Data” object to store information about the motor to be controlled. 
The Hierarchy of Motor Control Devices also supports a hierarchy of IO Assembly Instance 
definitions. Assembly instances are numbered within the hierarchy so that each device type is 
assigned a range of Assembly Instance numbers, with higher functionality devices supporting 
higher instance numbers. Devices in the hierarchy can choose to support some IO Assembly 
Instance numbers that are lower than theirs in the hierarchy. For example an AC Drive may 
choose to support some IO Assemblies that are defined in the Starter Profile to make it easier to 
interchange drives and starters in a system. 


Multiple axes on one drive 


It is possible to implement several axes of control on one physical drive unit. A serarate MAC 
ID must be assigned to each axis so each axis is treated as separate CIP node. 


Object Model 
The Object Model in figure 6-15.1 represents an AC or DC Drive. The table below indicates 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 
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Chapter 5, The CIP Object Library, provides more details about these objects. 


Object Class Optional / Required 
Identity Required 
Message Router Optional 
Network Specific Link Required 
Object 

Connection Required 
Assembly Required 
Control Supervisor Required 
AC/DC Drive Required 
Motor Data Required 
Parameter Optional 
Parameter Group Optional 


Discrete Input Optional 
Discrete Output Optional 
Analog Input Optional 
Analog Output Optional 


# of Instances 


1 
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Figure 6-15.7. Object Model for AC and DC Drives 
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6-15.2. 


6-15.3. 
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How Objects Affect Behavior 


The objects in this device affect the device's behavior as shown in the following table. 


Object 
Identity 
Message Router 


Network Specific 
Link Object 


Connection 
Assembly 
Control Supervisor 
AC/DC Drive 
Motor Data 
Parameter 
Parameter Group 
Discrete Input 
Discrete Output 
Analog Input 
Analog Output 


Effect on Behavior 
Supports the Reset service 
No effect 

Configures port attributes 


Logical ports into or out of the device 

Defines I/O data format 

Manages drive functions, operational states and control 
Provides drive configuration 

Defines motor data for the motor connected to this device 
Provides a public interface to device configuration data 
Provides an aid to device configuration 

Defines the behavior of discrete inputs on this device 
Defines the behavior of discrete outputs on this device 
Defines the behavior of analog inputs on this device 


Defines the behavior of analog outputs on this device 


Defining Object Interfaces 


The objects in this device have the interfaces listed in the following table. 


Object 
Identity 
Message Router 


Network Specific 
Link Object 


Connection 
Assembly 

Control Supervisor 
AC/DC Drive 
Motor Data 
Parameter 
Discrete Input 
Discrete Output 
Analog Input 
Analog Output 


Interface 

Message Router 

Explicit Message Connection 
Message Router 


Message Router 

I/O Connection or Message Router 

Message Router, Assembly or Parameter Object 
Message Router, Assembly or Parameter Object 
Message Router or Parameter Object 

Message Router 

Message Router or Assembly 

Message Router or Assembly 

Message Router or Assembly 


Message Router or Assembly 
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I/O Assembly Instances 


The IO Assembly Instance definitions in this section define the format of the “data” attribute 
(attribute 3) for IO Assembly Instances. Through the use of predefined instance definitions, IO 
Assemblies support a hierarchy of motor control devices. The device hierarchy includes motor 
starters, soft starters, AC and DC drives, and servo drives. Assembly Instances are numbered 
within the hierarchy so that each device type is assigned a range of Assembly Instance 
numbers, with higher functionality devices supporting higher instance numbers. Devices in the 
hierarchy can choose to support instance numbers that are lower than theirs in the 
hierarchy. For example an AC drive may choose to support some IO Assemblies that are 
defined in the starter profile to make it easier to interchange starters and drives within a system. 
The following table shows the Assembly Instance numbering for the motor control device 
hierarchy. 


Profile 1/O Type Instance Instances within 
Range hierarchy that may be 
implemented for this 
product type. 


Soft Start Starter 50-69 


The following IO Assembly Instances are defined for AC and DC Drives. 


Number Required/Optional Type Name 
decimal h 
4 


20 Output Basic Speed Control Output 
21 Output Extended Speed Control Output 
22 Output Speed and Torque Control Output 


23 Optional Output Extended Speed and Torque 
Control Output 


Output Process Control Output 
Output Extended Process Control Output 


Input Basic Speed Control Input 


Input Extended Speed Control Input 
Input Speed and Torque Control Input 


Optional Input Extended Speed and Torque 
Control Input 
Input Process Control Input 
Input Extended Process Control Input 


If a bit is not used in an IO Assembly, it is reserved for use in other Assemblies. Reserved bits 
in Output Assemblies are ignored by the consuming device. Reserved bits in Input Assemblies 
are set to zero by the producing device. 


24 
25 


70 
71 
72 
73 


74 
75 


ex 
14 
15 
16 
17 
18 
19 
46 
47 
48 
49 

A 
4B 


Reserved bits in the IO Assembly Data Attribute Format Tables are shaded. 
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6-15.4.1. Connection Paths to I/O Assembly Instances 


6-15.5. 


The IO Assembly Instances are chosen for IO Connections by setting the 
“produced _connection_path” (attribute 14) and “consumed _ connection path” (attribute 16) 
attributes in the appropriate connection object. 


AC and DC Drives use the Symbolic Segment Type (see Appendix C) to specify paths to the 
IO Assembly Instances in the Motor Control Hierarchy. IO Assembly Instances are represented 
by ASCH strings that contain the hex number of the Assembly Instance whose path is to be 
chosen. 


= a 


segment symbol size in ASCII 1 (3 1hex) ASCII 4 (34hex) 
type bytes (2 bytes) 
(symbolic) 


The following example shows the Symbolic Segment used to specify Output Assembly 
Instance 20 (14 hex). 


1/O Assembly Data Attribute Format 


The I/O Assembly Data Attributes have the format shown below. 


20 Fault Run 
jee Reset Fwd 
Speed Reference (Low Byte) 
Speed Reference (High Byte) 
21 NetRef | NetCtrl Fault Run Run 
ia = 
Speed Reference (Low Byte) 
Speed Reference (High Byte) 
22 Fault 
ial 
Speed Reference (Low Byte) 
Speed Reference (High Byte) 
Torque Reference (Low Byte) 
5 Torque Reference (High Byte) 
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23 


24 


25 


70 


7 


= 
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NetRef | NetCtrl Fault Run Run 
Reset Rev Fwd 


Speed Reference (Low Byte) 


Speed Reference (High Byte) 
Torque Reference (Low Byte) 
Torque Reference (High Byte) 


Fault Run 
Reset Fwd 
Speed Reference (Low Byte) 
Speed Reference (High Byte) 


Process Reference (Low Byte) 


Process Reference (High Byte) 


NetProc | NetRef | NetCtrl Fault Run Run 
Reset Rev Fwd 


Mode 
Speed Reference (Low Byte) 
Speed Reference (High Byte) 
Process Reference (Low Byte) 


Process Reference (High Byte) 
1 


Speed Actual (Low Byte) 
Speed Actual (High Byte) 


At Ref Ctrl Ready | Runnin | Running | Warnin | Faulted 
Referen | From | From g2 1 g 
ce Net Net (Rev) (Fwd) 


Drive State 
Speed Actual (Low Byte) 
Speed Actual (High Byte) 


Faulted 
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Instance [Bits | [Bit2 | [Bit1 | Bit 0 


Speed Actual (Low Byte) 
Speed Actual (High Byte) 
Torque Actual (Low Byte) 
Torque Actual (High Byte) 


Ctrl Ready | Runnin | Running 
Roe From las 


Drive State 
Speed Actual (Low Byte) 
Speed Actual (High Byte) 
Torque Actual (Low Byte) 
Torque Actual (High Byte) 


Runnin Faulted 
gl 


Speed Actual (Low Byte) 

Speed Actual (High Byte) 

Process Actual (Low Byte) 
Process Actual (High Byte) 


At Ref Ctrl Ready 
Referen | From From 
ce Net Net 


Drive State 
Speed Actual (Low Byte) 
Speed Actual (High Byte) 
Process Actual (Low Byte) 
Process Actual (High Byte) 


Faulted 
g 


— 
Ww 


Runnin | Runnin 


Faulted 
g 


6-15.6. Mapping I/O Assembly Data Attribute Components 


The following table indicates the I/O Assembly Data Attribute mapping for AC and DC Drive 
Output Assemblies. 


Data Component Name Instance Attribute 
Number Number 


Supervisor 
sad 
Supervisor 
Supervisor 
Supervisor 
Drive 


Net Proc AC/DC 5 
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Data Component Name Instance Attribute 
Number Number 
Prive ff ft __ 


Drive Mode AC/DC 2Anex DriveMode 6 
Drive 
Drive 

Torque Reference AC/DC 2Anex 1 TorqueRef 12 
Drive 

Process Reference AC/DC 2Atex 1 ProcessRef 14 
Drive 


The following table indicates the I/O Assembly Data Attribute mapping for AC and DC Drive 
Input Assemblies. 


Data Component Name Instance Attribute 


Name Number | Name | Number 


Faulted Control 29 hex = 10 
Supervisor 

Warning Control 29 nex Warning 11 
Supervisor 


Running! (Fwd) Control 29 nex 1 Running! 7 
Supervisor 

Running2 (Rev) Control 29 nex 1 Running2 8 
Supervisor 

Ready Control 29n ex 1 Ready 9 
Supervisor 

CtrlFromNet Control 29 nex 1 CtrlFromNet 15 
Supervisor 

6 


Drive State Control 29nex 1 State 
Supervisor 
Ref From Net AC/DC 2Atex 1 RefFromNet 29 
Drive 


At Reference AC/DC 2Atex 1 AtReference 3 
Drive 

Speed Actual AC/DC 2Anex 1 SpeedActual 7 
Drive 

Torque Actual AC/DC 2Anex 1 TorqueActual 11 
Drive 

13 


Process Actual AC/DC 2Atex 1 ProcessActual 
Drive 


6-15.7. Defining Device Configuration 


Public access to the Control Supervisor Object, the Motor Data Object, and the AC/DC Drive 
Object must be supported for configuration of an AC or DC drive. If supported, the optional 
Parameter Objects may be used to access the various configuration attributes in the Control 
Supervisor Object, the Motor Data Object, and the AC/DC Drive Object. 
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AC and DC drives may contain (but are not limited to) any of the Parameter Object instances 
listed in the table below. Suggested parameter names are also given in the table. The set of 
parameters instances that are supported by a drive should be numbered sequentially with lower 
instance numbers assigned to parameters that appear earlier in the table. Vendor specific 
parameter instances should be numbered sequentially following the instances that appear in the 


following table. 


Parameter Object instances may be implemented as EDS file definitions, parameter stubs, or 
full parameter objects. See Chapter 5 of the CIP Common specification for a definition of the 
Parameter Object and an explanation of how it is used for configuration. 


6-15.7.1. Mapping Parameter Object Data 

The following table indicates the Parameter Object data mapping for an AC or DC Drive 
device. 

Configuration Instance Attribute 
Parameter 

Nine Nubey Number 
Motor Vendo 7 
Motor Rated Car 
Motor Rated Vol 
Motor Rated Pwr 7 5 
Motor Max Speed i 
Motor Base Speed i 
Service Factor 9 
Running Fwd 29 ex 7 
Running Rev 29 ex 8 
Ready 29x 9 
Faulted 29 ex 10 
Warning 29 ex u 
Fault Reset 29 ex 12 
Fault Code 29 ex 13 
Warning Code 29 ex 14 
Control From Net 29x 15 
DN Fault Mode 29 ex 16 
Force Fault 29 ex 17 
Force Status 29 ex 18 
At Reference 2Aex 3 
Network Ref 2Atex 4 
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Configuration Class 
Parameter 


Attribute 


Name Name Number 
Network Process 5 
Drive Mode 6 
Speed Actual 7 
Speed Reference 8 
Current Actual 9 
Current Limit 10 
Torque Actual u 
Torque Reference 12 
Process Actual 13 
Process Reference 14 
Power Actual 15 
Input Voltage 16 
Output Voltage 17 
Accel Time 18 
Decel Time 19 
Low Speed Limit 20 
High Speed Limit 21 
Speed Scale 22 
Current Scale 23 
Torque Scale 24 
Process Scale 25 
Power Scale 26 
Voltage Scale 27 
Time Scale 28 
Ref From Net 29 
Proc From Net 30 
Field I or V 31 
Field Voltage Ratio 32 
Field Cur Set Pt 33 
Field Weak Ena 34 
Field Cur Actual 35 
Field Min Cur 36 


6-15.7.2. Parameter Group Objects 


AC and DC drives may contain (but are not limited to) any of the Parameter Group Object 
Instances listed in the table below. If Parameter Groups are supported, Parameter Instances 
should be grouped according to the object that their data is mapped to. For example, all 
Parameters Instances whose data maps to the Motor Data Object should be contained in the 
Motor Group (Parameter Group Object Instance 1). 


Parameter Group Object instances may be implemented from an EDS file, or as actual 


Parameter Group objects from the device. See Chapter 5 of the CIP Common specification for a 
definition of the Parameter Group Object. 
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Parameter 
Group Name 
Motor 


Supervisor 


Instance 
Number 


1 


Parameters in Group 


Motor Type 
Motor Cat Number 
Motor Vendor 
Motor Rated Cur 
Motor Rated Volt 
Motor Rated Pwr 
Motor Rated Freq 
Motor Rated Temp 
Motor Max Speed 
Motor Pole Count 
Motor Torq Const 
Motor Inertia 
Motor Base Speed 
Motor Field Cur 
Min Field Cur 
Rated Field Volt 
Rated Field Volt 
Service Factor 
Network Control 
Drive State 
Running Fwd 


Running Rev 
Ready 

Faulted 
Warning 

Fault Reset 
Fault Code 
Warning Code 
Control From Net 
DN Fault Mode 
Force Fault 
Force Status 
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Parameter Instance Parameters in Group 
Group Name Number 
Drive 3 At Reference 


Network Ref 
Network Process 
Drive Mode 
Speed Actual 
Speed Reference 
Current Actual 
Current Limit 
Torque Actual 
Torque Reference 
Process Actual 
Process Reference 
Power Actual 
Input Voltage 
Output Voltage 
Accel Time 
Decel Time 

Low Speed Limit 
High Speed Limit 
Speed Scale 
Current Scale 
Torque Scale 
Process Scale 
Power Scale 
Voltage Scale 
Time Scale 

Ref From Net 
Proc From Net 
Field I or V 

Field Voltage Ratio 
Field Cur Set Pt 
Field Weak Ena 
Field Cur Actual 
Field Min Cur 
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6-16. SERVO DRIVES 
This device profile for a Servo Drive is presently under development. It is intended that this 


profile will be defined by the Servo Drive SIG of the Open DeviceNet Vendor Association, 
Inc. and ControlNet International. 
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6-17. BARCODE SCANNER 


The profile for this device type will be defined by the Open DeviceNet Vendor Association, 
Inc.and ControlNet International 
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6-18. 


6-18.1. 


6-18.1.1. 
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POSITION CONTROLLER 
Device Type: 10hex 


A Position Controller controls the motion and position of a motor or linear actuator (servo, 
stepper, etc.). The position controller may or may not include an integrated drive. Positioning is 
achieved with a controlled motion profile. The motion profile is defined by Acceleration, 
Velocity, Deceleration, Position or Torque. 


Object Model 


The Object Model in figure 6-12.1 represents a Position Controller Device. The table below 
indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Chapter 5, The CIP Object Library, provides more details about these objects. 


Object Class # of Instances 
Identity 1 
Message Router 1 
Network Specific Link Object 1 
Connection 2 (explicit/ I/O) 
Position Controller Supervisor 1 per Axis 
Position Controller 1 per Axis 
Command Block : 
Block Sequencer 1_per Axis 
Drive | per Axis 
Motor Data 1 per Axis 
Parameter : 
Model Description 


The object model shown below describes how the Position Controller device is controlled 
through CIP. Attributes can be set and queried in the normal manner for configuration. The 
Position Controller object handles the interface to the internal or external drive unit. The motor 
and drive units can be servo, stepper or some other method with optional feedback (open or 
closed loop). 


In addition, the Command Block objects and the Block Sequencer object can be used to 
perform complex moves, modify attributes or wait for attributes to become valid. Command 
Blocks can be linked together to form a command chain with branching and looping supported. 
The user can download command block sequences during configuration and execute them at 
any time to perform complex moves or modify attributes. The Block Sequencer object is 
accessible through the I/O command message giving the user the ability to perform complex 
motion sequences from a PLC or scanner card. 


Figure 6-18.1 Object Model for a Position Controller 
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How Objects Affect Behavior 


The object for this device affect the device’s behavior as shown in the table below. 


Object 
Identity 
Message Router 
Network Specific Link Object 
Connection 
Position Controller Supervisor 
Position Controller 
Block Sequencer 
Command Block 
Drive 
Motor Data 
Parameter 


Effect on behavior 
Supports the Reset service 
No effect 
Configures port attributes 
Contains the number of logical ports into or out of the device 
Handles faults, home and registration inputs and modifies meaning of I/O data 
Provides positioning control and manages interface to power amplifier 
Executes command block sequences 
Defines the behavior of command blocks 
Manages power amplifier 
Configures the power amplifier for motor parameters 
Defines the behavior of Parameters 
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6-18.3. Defining Object Interfaces 


The objects in this device have the interfaces listed in the following table: 


Object Interface 
Identity Message Router 
Message Router Explicit Messaging Connection 


Network Specific Link Object | Message Router 
Connection Message Router 


Position Controller Supervisor | Message Router or Position Controller Supervisor Class 


Position Controller Message Router or Position Controller Supervisor Class 
Block Sequencer Message Router or Position Controller Supervisor Class 
Command Block Message Router or Position Controller Supervisor Class 
Drive Message Router or Position Controller Supervisor Class 
Motor Data Message Router or Position Controller Supervisor Class 
Parameter Message Router 


6-18.4. I/O Connection Messages 


The Position Controller Profile supports both command and response messages via the I/O 
connection. The produced and consumed paths specify the Position Controller Supervisor Class 
attributes as shown in Figure 6-12.1. 


6-18.4.1 Message Formats 


The Position Controller Profile supports multiple axes per CIP node by allowing up to seven 
instances of each of the axis objects, in one Position Controller device. The axis objects are the 
1) position controller supervisor, 2) position controller: 3) drive: 4) motor data: and 5) block 
sequencer. The I/O message can contain data from more than one axis object. The Command 
Axis Number and the Response Axis Number shown in the Message Format specifies the 
instance number of the axis object whose data is contained in the I/O message. 


Command Message Format 


Enable Reg A Hard Smooth | Direction | Incremental Start Load Data/ 
Stop Stop (V. Mode) Block | Start Profile 


Command Data 1 


Command Axis Number Command Message Type 


Command Data 2 
Command Data 3 


Command Data 4 


Command Data 5 
7 Command Data 6 
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Response senate Format 


Enable Reg Level es 2 General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Response Data 1 


Load Block Fault |} FE Fault | Negative Positive | Rev Limit | Fwd Limit | Fault Input 
See Limit Limit Fault 


Response Axis Number = Message Type 


a a 
es 


Note that a response message may contain data for a different axis number from what was 
contained in the command message. If an error is detected in the command or its requested 
response message, the response message shall be Command/Response Error Message Type 14 
hex, not the requested response message. 


Definition of a Profile Move 


A profile move is a move that uses Acceleration, Target Velocity, and Deceleration to run at a 
Target Velocity or to a Target Position. In addition, the position controller device can output a 
Torque command. Whether or not the position controller device runs at a Target Velocity, toa 
Target Position or outputs a Torque command depends on the Operating Mode (Position 
Controller Object Attribute 3), to which the position controller device is set. The position 
controller device is set to Position, Velocity or Torque Mode using Position Controller Object 
Attribute 3. 


Starting a Profile Move 


The Position Controller Profile is mode-sensitive. The Position Controller Object Attribute 3 
sets the mode of the controller to the following: 


0 = Position (default) 
1 = Velocity 
2 = Torque 
A profile move starts when the command message type for the specified mode is loaded and the 


Load Data/Start Profile bit transitions from zero to one. The table below shows the command 
message type which starts a profile move for each mode. 


Mode (Attribute 3) Command Message Type which Starts Motion 
0 = Position 01 = Position 

1 = Velocity 02 = Velocity 

2 = Torque 05 = Torque 
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6-18.4.4 I/O Handshaking Procedure 


Proper handshaking between the client and the server is essential in I/O messaging to ensure 
that data sent to the position controller device is properly received. Two bits are used to 
provide handshaking between command and response messages. The recommended 
handshaking procedure for the client is described in Flowcharts A and B below. The behavior 
required from the server to implement the handshake procedure is described in Flowcharts C 
and D. Refer to the timing diagram below for representative timing of these bits during the 
handshake sequence. 


Flowchart A: Client Data Loading Procedure 


Load Command Data Values, 

Command Axis Number, and 

Command Type into Command 
Message 


Set Load Data/Start Profile 
bit=1 


Is Load Data 
Complete bit in 
response message 
=1? 


Yes 
Set Load Data/Start Profile 
bit= 0 


Is Load Data 
Complete bit in 
response message 
=0? 
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Flowchart B: Client Profile Move Procedure 


Call Client Data Loading 
Procedure 


Is Profile in 
Progress bit in 
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Release 1.0 Open DeviceNet Vendor Assoc. & ControlNet International 6-67 


Chapter 6: Device Profiles Volume 1: CIP Common Specification 


Flowchart C: Server Behavior 
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Flowchart D: Profile Monitoring Procedure 
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Load Data 
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* Data Successfully Loaded into Position Control Object 


Release 1.0 


Deceleration 
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6-18.5. 


1/O Connection Message Types 


6-18.5.1. Command Message Types 


6-70 


The command message type is defined by byte 02 of the message. Byte 00 is the same for all 
command message types. Bytes 01 and 03 through 07 are defined by the Command Message 
Type code in byte 02. In message types 01 through 05, byte 03 defines the requested Response 
axis number and Response Message Type format. For message types 19 hex through 1F hex, 
the requested Response axis number and Response Message Type is the same as the Command 
axis number and Command Message Type. 


Command Message Type _01 hex Target Position - Optional 


Enable Reg Arm Hard Smooth | Direction | Incremental | Start Load Data/ 
Stop Stop (V. Mode) Block | Start Profile 
Block # 


Command Axis Number Command Message Type 


Response Axis Number Response Message Type 
Target Position Low Byte 


5 Target Position Low Middle Byte 


| 6 | Target Position High Middle Byte 


Target Position High Byte 


Command Message Type 02 hex Target Velocity - Optional 
Byte 
Enable Reg Arm Hard Smooth | Direction | Incremental | Start Load Data/ 
(al wa | st | Si Pa 
ee 
Command Message Type 


3 Response Axis Number Response Message Type 
Target Velocity Low Byte 

Target Velocity Low Middle Byte 

Target Velocity High Middle Byte 
Target Velocity High Byte 


— 


a 


Command Message Type 03 hex Acceleration - Optional 
Byte _| Bit 7 
Enable Reg Arm Hard Smooth Direction | Incremental | Start | Load Data/ 
Meh [sep | SS" | cava || sss | si rt 
pies =| SS eee es ABO | 2. 
3 Response Axis Number 
4 


5 Acceleration Low Middle Byte 
Acceleration High Middle Byte 


7 Acceleration High Byte 


faa | 
po = | 
5 S| 
| 6 | 
ai 
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Command Message Type 04 hex Deceleration - Optional 


Enable Reg Arm Hard Smooth Direction | Incremental | Start | Load Data/ 
Stop Stop (V. Mode) Block | Start Profile 
Block # 


Command Axis Number Command Message Type 


Response Axis Number Response Message Type 
Deceleration Low Byte 


Deceleration Low Middle Byte 
Deceleration High Middle Byte 
Deceleration High Byte 


Command Message Type 05 hex Torque - Optional 

Enable Reg Arm Hard Smooth Direction | Incremental | Start | Load Data/ 
pO | Ps | Bet | se | "Sep Lev oan | | nics | sn | 
Block # 
Response Message Type 
Torque Low Byte 
Torque Low Middle Byte 
Pp 6 | Torque High Middle Byte 


Torque High Byte 


Command Message Type 19 hex Motor Data Attribute - Optional 


Enable Reg Arm Hard Smooth Direction | Incremental | Start | Load Data/ 
Stop Stop (V. Mode) Block | Start Profile 
Motor Data Attribute to Get 


Command Axis Number Command Message Type 


Motor Data Attribute to Set 


Motor Data Attribute Value Low Byte 


Motor Data Attribute Value Low Middle Byte 
Motor Data Attribute Value High Middle Byte 


Motor Data Attribute Value High Byte 


Command Message Type 1A hex Position Controller Supervisor Attribute - Optional 


Release 1.0 


Enable Reg Arm Hard Smooth Direction | Incremental | Start | Load Data/ 
Stop Stop (V. Mode) Block | Start Profile 


1 Position Controller Supervisor Attribute to Get 


Command Axis Number Command Message Type 


| 6 | Position Controller Supervisor Attribute Value High Middle Byte 
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Command Message Type 1B hex Position Controller Attribute - Optional 


Enable Reg Arm Hard Smooth Direction | Incremental | Start | Load Data/ 
Stop Stop (V. Mode) Block | Start Profile 
Position Controller Attribute to Get 


Command Axis Number Command Message Type 


Position Controller Attribute to Set 
Position Controller Attribute Value Low Middle Byte 
Position Controller Attribute Value High Middle Byte 
Position Controller Attribute Value High Byte 


Command Message Type 1C hex Block Sequencer Attribute - Optional 
Enable Reg Arm Hard Smooth Direction | Incremental | Start | Load Data/ 

pO Reme LBee | ste | “Sep Leva | | nice | sr | 
Block Sequencer Attribute to Get 
Block Sequencer Attribute to Set 
Block Sequencer Attribute Value Low Byte 
Block Sequencer Attribute Value Low Middle Byte 
| 6 | “Block Sequencer Attribute Value High Middle Byte 


Block Sequencer Attribute Value High Byte 


Command Message Type 1D hex Drive Attribute - Optional 
Enable Reg Arm Hard Smooth Direction | Incremental | Start | Load Data/ 
Stop Stop (V. Mode) Block | Start Profile 
Drive Attribute to Get 


Command Message Type 
Drive Attribute to Set 
Drive Attribute Value Low Middle Byte 
Drive Attribute Value High Middle Byte 
Drive Attribute Value High Byte 


Command Message Type 1E hex Command Block Attribute - Optional 


Enable Reg Arm Hard Smooth Direction | Incremental | Start | Load Data/ 
Stop Stop (V. Mode) Block | Start Profile 
Command Block Attribute to Get/Set 


Command Axis Number Command Message Type 


| 6 | Command Block Attribute Value High Middle Byte 
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Command Message Type 1F hex Parameter - Optional 


Enable Reg Arm Hard Smooth Direction | Incremental | Start | Load Data/ 
Stop Stop (V. Mode) Block | Start Profile 
Parameter Instance to Get 


Command Axis Number Command Message Type 


Parameter Instance to Set 


Parameter Value Low Byte 


Parameter Value Low Middle Byte 
Parameter Value High Middle Byte 
Parameter Value High Byte 


Semantics: 

Load Data/ Start Profile 

Set from zero to one to load command data. The transition of this bit from zero to one will also 
start a Profile Move when the command message type contained in the command message field 
is the message type that starts a Profile Move for the mode selected. Refer to Section 6-18.4.3 
for an explanation of what commands start a Profile Move for a given mode. 


Start Block 


This bit is used to execute a Command block or Command block chain. Set from zero to one to 
execute a command block or command block chain. 


Incremental 


This bit is used to define the position value as either absolute or incremental. 0 = absolute 
position value and 1 = incremental position value. 


Direction 


This bit is used to control the direction of the motor in Velocity mode. A 1 = forward, positive 
and a 0) = reverse, negative. 


Smooth Stop 


This bit is used to bring the motor to a controlled stop at the currently implemented 
deceleration rate. 


Hard Stop 
This bit is used to bring the motor to an immediate stop. 
Arm 


This bit is used to arm the registration input. When the registration input is triggered, the 
registration action will be executed. 
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Enable 


This bit is used to control the enable output. Clearing this bit will set the enable output inactive 
and the currently executing motion profile will be aborted. 


Block # 


This byte defines the block number to be executed when the Start Block bit transitions from 
zero to one. 


Command Message Type 

This field defines the Command Message Type Response Message Type 

This field defines the Response Message Type 

Command Axis Number 

These three bits define the Consumed Axis Connection attribute of the Position Controller 
Supervisor class. This attribute value specifies the instance number of all of the axis objects 


whose data are contained in the I/O command message. The command axis number is 
specified as shown in the table below: 


Command Axis Number Byte 2 


NINA] NPR] WPM ele 


Note that axis 1 can be specified by either 0 or 1. Axis zero is not allowed. 
Target Position - Command Message Type 01 hex 


This double word defines the Profile Move’s Target Position in position units, when the Load 
Data /Start Profile bit transitions from zero to one. 


Target Velocity - Command Message Type 02 hex 


This double word defines the Profile Move’s Target Velocity in profile units, when the Load 
Data /Start Profile bit transitions from zero to one 


Acceleration - Command Message Type 03 hex 


This double word defines the Profile Move’s Acceleration in profile units, when the Load Data 
/Start Profile bit transitions from zero to one.. 
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Deceleration - Command Message Type 04 hex 


This double word defines the Profile Move’s Target Position in profile units, when the Load 
Data /Start Profile bit transitions from zero to one 


Torque - Command Message Type 05 hex 

This double word is used to set the output torque, when the Load Data /Start Profile bit 
transitions from zero to one. The torque value will only take effect when in torque mode. 
(Position Controller Object Attribute 3 = 2) 

Attribute Value — Command Message Types 19 — 1E hex 


This double word defines the value of the attribute to set, when the Load Data/Start Profile bit 
transitions from zero to one. 


Object Attribute to Get — Command Message Types 19 — 1D hex 
This byte defines the object attribute to get the value of and return in the response message. 
Object Attribute to Set — Command Message Types 19 — 1D hex 


This byte defines the object attribute to set to the new value defined by the Attribute Value 
when the Load Data/Start Profile bit transitions from zero to one. 


Command Block Attribute to Get/Set — Command Message Type 1E hex 


This byte defines the attribute of the Command Block Object Instance to get/set, when the 
Load Data/Start Profile bit transitions from zero to one. 


Command Block Instance to Get/Set - Command Message Type 1E hex 


This byte defines the instance of the Command Block Object for which the attribute is being 
get/set, when the Load Data/Start Profile bit transitions from zero to one. 


Parameter Instance to Get - Command Message Type 1F hex 


This byte defines the instance of the parameter object to get the value of and return in the 
response message. 


Parameter Instance to Set - Command Message Type 1F hex 


This byte defines the instance of the parameter object to set to the new value defined by the 
Parameter Value, when the Load Data/Start Profile bit transitions from zero to one. 


Parameter Value - Command Message Type 1F hex 


This double word defines the value of the parameter to set, when the Load Data/Start Profile bit 
transitions from zero to one. 
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Response Message Types 


The response message type is defined by byte 03 of the message. Bytes 00, 02 and 03 are the 
same for all response message types. Bytes 01 and 04 through 07 are defined by the Response 
Message Type code in byte 03. 


Response Message Type 01 hex Actual Position - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Executing Block Number 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
a ke Limit Limit le Fault 


Response Axis Number Response Message Type 


SY Actual Position Low Byte 
LE 5e || Actual Position Low Middle Byte 
| 6 | Actual Position High Middle Byte 


er | Actual Position High Byte 


Response Message Type 02 hex Command Position - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Executing Block Number 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
aot ee Limit Limit a Fault 


Response Axis Number Response Message Type 
— Commanded Position Low Byte 


a5, Commanded Position Low Middle Byte 
ht6 | Commanded Position High Middle Byte 


7 Commanded Position High Byte 


Response Message Type 03 hex Actual Velocity - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Executing Block Number 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
ee Limit Limit oe Fault 


Response Axis Number Response Message Type 


—_ Actual Velocity Low Byte 
Ew Actual Velocity Low Middle Byte 
ke | Actual Velocity High Middle Byte 


Pe) Actual Velocity High Byte 
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Response Message Type 04 hex Command Velocity - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Executing Block Number 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
ane Limit Limit aan Fault 


Response Axis Number Response Message Type 


— Commanded Velocity Low Byte 
Commanded Velocity Low Middle Byte 
| 6 | Commanded Velocity High Middle Byte 


7 Commanded Velocity High Byte 


Response Message Type 05 hex Torque - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Executing Block Number 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
Se ee Limit Limit ae Fault 
Response Axis Number Response Message Type 


a Torque Low Byte 
| Torque Low Middle Byte 
Pp 6 | Torque High Middle Byte 
eee | Torque High Byte 


Response Message Type 06 hex Captured Home Position - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Executing Block Number 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
See Limit Limit oa Fault 


Response Axis Number Response Message Type 
— Home Position Low Byte 


i, S| Home Position Low Middle Byte 
367 | Home Position High Middle Byte 


7 Home Position High Byte 


Response Message Type 07 hex Captured Index Position - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Executing Block Number 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
roe Re Limit Limit oa Fault 


Response Axis Number Response Message Type 


= Index Position Low Byte 
Hs Se] Index Position Low Middle Byte 


aa Index Position High Middle Byte 


| 7 | Index Position High Byte 
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Response Message Type 08 hex Captured Registration Position - Optional 


Enable | Reg Level Home Current | General | On Target | Blockin | Profile -in 
Level Direction Fault Position | execution Progress 


Executing Block Number 


Load Block Fault Negative | Positive | Rev Limit Fault Input 
ae ae Limit Limit oon Fault 


Response Axis Number Response Message Type 


— Registration Position Low Byte 
Registration Position Low Middle Byte 
| 6 | Registration Position High Middle Byte 


7 Registration Position High Byte 


Response Message Type 14 hex Command/Response Error — Required 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Reserved = 0 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
Se ee Limit Limit ae Fault 
Response Axis Number Response Message Type 


General Error Code 


a 
| Additional Code 
| 6 | Copy of Command Message Byte 2 


eye] Copy of Command Message Byte 3 


Response Message Type 19 hex Motor Data Attribute - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Motor Data Attribute to Get 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
Sa Re Limit Limit oa Fault 


Response Axis Number Response Message Type 
— Motor Data Attribute Value Low Byte 


es --.| Motor Data Attribute Value Low Middle Byte 
ae Motor Data Attribute Value High Middle Byte 


iL Motor Data Attribute Value High Byte 


Response Message Type 1A hex Position Controller Supervisor Attribute - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Position Controller Supervisor Attribute to Get 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
roe Re Limit Limit na Fault 


Response Axis Number Response Message Type 


= Position Controller Supervisor Attribute Value Low Byte 
Hs Se] Position Controller Supervisor Attribute Value Low Middle Byte 


aa Position Controller Supervisor Attribute Value High Middle Byte 


i ae | Position Controller Supervisor Attribute Value High Byte 
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Response Message Type 1B hex Position Controller Attribute - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Position Controller Attribute to Get 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
ane Limit Limit aan Fault 


Response Axis Number Response Message Type 
= Position Controller Attribute Value Low Byte 


254 Position Controller Attribute Value Low Middle Byte 
| 6 | Position Controller Attribute Value High Middle Byte 


7 Position Controller Attribute Value High Byte 


Response Message Type 1C hex Block Sequencer Attribute - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Block Sequencer Attribute to oa 


Load Block Fault | FE Fault | Negative | Positive Fault Input 
Se oe Limit Limit a ies Fault 
Response Axis Number Response Message Type 


a Block Sequencer Attribute Value Low Byte 
ee oe | Block Sequencer Attribute Value Low Middle Byte 


| 6 | Block Sequencer Attribute Value High Middle Byte 


ee | Block Sequencer Attribute Value High Byte 


Response Message Type 1D hex Drive Attribute - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Drive Attribute to Get 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
See Limit Limit oa Fault 


Response Axis Number Response Message Type 
— Drive Attribute Value Low Byte 


i es -.| Drive Attribute Value Low Middle Byte 
=a Drive Attribute Value High Middle Byte 


ei Drive Attribute Value High Byte 


Response Message Type 1E hex Command Block Attribute - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Command Block Attribute to Get 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
roe Re Limit Limit oa Fault 


Response Axis Number Response Message Type 


= Command Block Attribute Value Low Byte 
Hs Se S] Command Block Attribute Value Low Middle Byte 


aa Command Block Attribute Value High Middle Byte 


i ae | Command Block Attribute Value High Byte 
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Response Message Type 1F hex Parameter - Optional 


Enable | Reg Level Home Current | General | On Target | Block in Profile in 
Level Direction Fault Position | execution Progress 


Parameter Instance to Get 


Load Block Fault | FE Fault | Negative | Positive | Rev Limit Fault Input 
aoe Limit Limit aan Fault 


Response Axis Number Response Message Type 


— Parameter Value Low Byte 
Parameter Value Low Middle Byte 
| 6 | Parameter Value High Middle Byte 


7 Parameter Value High Byte 


Semantics: 


Profile in Progress 
This bit indicates that a profile move is in progress. 
Block in Execution 


This bit indicates that a block is in execution. The command block that is currently being 
executed is returned in byte 1. 


On Target Position 


This bit indicates whether or not the motor is on the last targeted position. (1 = Current position 
equals the last target position.) 


General Fault 

This bit indicates the logical “or” of all fault conditions. 

Direction 

This bit shows the current direction of the motor. If the motor is not moving the bit will 
indicated the direction of the last commanded move. 0 = reverse or negative direction and | = 
forward or positive direction. 

Home Level 

This bit reflects the level of the home input. 

Reg Level 

This bit reflects the level of the registration input. 


Enable 


This bit indicates the state of the enable output. A 1 indicates the enable output is active. 
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Executing Block # 

This byte defines the currently executing block if the Block In Execution bit is active. 

Fault Input Fault 

This bit indicates that the fault input is active. 

Fwd Limit 

This bit indicates that the forward input is active. 

Rev Limit 

This bit indicates that the reverse input is active. 

Positive Limit 

This bit indicates that the motor has attempted to travel past the programmed positive limit 
position. This bit remains valid until the motor is moved within the limits or the programmed 
limit value is set greater than the current position. 

Negative Limit 

This bit indicates that the motor has attempted to travel past the programmed negative limit 
position. This bit remains valid until the motor is moved within the limits or the programmed 
limit value is set less than the current position. 

FE Fault 

This bit indicates that a following error fault has occurred. This fault occurs when the following 
error, or difference between the commanded and actual position, exceeds the programmed 
allowable following error. 

Block Fault 

This bit indicates that a block execution fault has occurred. When this happens block execution 
and motion will cease. This bit is reset when Block Sequencer Block Fault Code attribute 


(Block Sequencer class, attribute 5) is read. Load Complete 


This bit indicates that the command data contained in the command message has been 
successfully loaded into the device. 


Response Message Type 


This byte defines the Response Message Type 
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Response Axis Number 


These three bits report the Produced Axis Connection attribute of the Position Controller 
Supervisor class. This attribute value specifies the instance number of all of the axis objects 
whose data is contained in the I/O response message. 


Response Axis Byte 2 

a aT a a ae 0 

a a 
a a a ae ae 0 
a a ee es ee i 
CS 0 
Ss) koe 
6 0 
7 l 


Note that axis 1 can be reported as either binary 0 or 1. Axis zero is not allowed. 
Actual Position - Response Message Type 01 hex 


This double word reflects the actual position in position units. If position feedback is not used, 
this word will report the commanded position. 


Commanded Position - Response Message Type 02 hex 

This double word reflects the commanded or calculated position in position units. 
Actual Velocity - Response Message Type 03 hex 

This double word reflects the actual velocity in profile units. 

Command Velocity - Response Message Type 04 hex 

This double word reflects the commanded or calculated velocity in profile units. 
Torque - Response Message Type 05 hex 

This double word reflects the torque. 

Home Position - Response Message Type 06 hex 

This double word reflects the captured home position in position units. 

Index Position - Response Message Type 07 hex 

This double word reflects the captured index position in position units. 
Registration Position - Response Message Type 08 hex 


This double word reflects the captured registration position in position units. 
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General Error Code — Response Message Type 14 hex 


This byte identifies an error has been encountered. The table below summarizes specific 
behavior for the Position Controller Profile. See Appendix H for a complete list of General 
Error codes. 


General | Additional Response Semantics 
Error Code 
Code 
O8hex Ol nex Service Not Supported Command Message type not supported. 
Additional code 01 takes precedence over 
| additional code 02. ' 
Response message type not supported. 
O5hex Consumed axis number was requested that does 
not exist in the drive. 
A produced axis number was requested that does 
not exist in the drive. 
09 hex Invalid Attribute Value Load value is out of range. 
OE nex A request to modify a non-modifiable attribute 
was received. 
13hex Not Enough Data I/O command message contained fewer than 8 
bytes. 
14rex Attribute specified in request was not supported. 


' If Response Message Type is supported and Command Message Type is not supported, a 
General Error Code 08, Additional Code 01 shall be returned. 


Additional Code — Response Message Type 14 hex 

This byte contains an object/service-specific value that further describes the error condition. If 
the responding object has no additional information to specify, then the value FF). is placed 
within this field. 

Attribute Value — Response Message Types 19 — 1E hex 

This double word reflects the value of the attribute to get. 

Object Attribute to Get — Response Message Types 19 — 1E hex 

This byte defines the object attribute from which to get the value. 


Parameter Instance to Get - Response Message Type 1F hex 


This byte defines the instance of the parameter object to get the value of and return in the 
response message. 


Parameter Value - Response Message Type 1F hex 


This double word reflects the value of the parameter to get. 
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6-18.6. Mapping I/O Message Data Attribute Components 
The following table indicates the I/O Data Attribute mapping for the Position Controller Profile 
Command Messages. 
Data Component Instan Data 
epauet ae ee 8 es 
Numbe 
r 
Load Data/ Start Position Controller | 25yex 1-7 Load Data/ Profile 11 | BOOL 
Start Block BOOL 
Incremental BOOL 
Direction BOOL 
Smooth Stop BOOL 
Hard Stop 21 | BOOL 
Supervisor 
Enable BOOL 
Block # USINT 
Command Axis Position Ctrl 24nex Consumed Axis 32 | USINT 
re [SweworCas || 9 [Numb | 
Type Supervisor Type 
Response Axis Position Ctrl 2A4nex 1-7 Produced Axis 33 | USINT 
ae Fees ea tn a Fe 
Response Message Position Ctrl 24nex 1-7 Rspnc Message 7 | USINT 
Tae ee ee 
Target Position | Position Controller | 25, | 1-7 | Target Position |__| DINT 
Target Velocity DINT 
Acceleration | Position Controller | 25ye, | _1-7__[ Acceleration __|_8_| DINT 
Deceleration | Position Controller | 25, | _1-7__| Deceleration | _9_| DINT 
Torque DINT 
Parameter Value Parameter OF nex | 1-255 | Parameter Value 1 Determined 
by instance 
of 
a | i parameter 
The following table indicates the I/O Data Attribute mapping for the Position Controller Profile 
Response Messages. 
Data Component Instance Data 
Name Number [Name | # | __Type 
Profile in Progress Profile in 11 BOOL 
Block in Execution | Block Block 2 BOOL 
On Target Position | Position 25 On Position 12 BOOL 
eked ae 
General Fault Position Ctrl | 24nex General Fault | 5 BOOL 
Direction Position 25 Direction 23 BOOL 
eee | 
Home Level Position Ctrl | 24nex Home Input 16 BOOL 
Reg Level Position Ctrl | 24nex Registration 22 BOOL 
Supervisor fal Input Level a | 
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Data Component Instance Attribute 


Name 
Enable State 


Executing Block # 
Fault Input Fault 
Fwd Limit 

Rev Limit 
Positive Limit 


Negative Limit 


FE Fault 
Block Fault 
Load Complete 


Response Axis 
Number 


Response Message 
Type 
Actual Position 


Commanded 
Position 


Actual Velocity 
Commanded 
Velocity 
Torque 

Home Position 
Index Position 
Registration 


Position 


Parameter Value 
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Block 
Sequencer 
Position Ctrl 
Supervisor 
Position 
Controller 
Position 
Controller 
Position 
Controller 


Position 


Controller 


Position 
Controller 
Block 
Sequencer 
Position 
Controller 


Position Ctrl 


Supervisor 
Class 


Position Ctrl 
Supervisor 


Position 
Controller 


Position 
Controller 


Position 
Controller 


Position 
Controller 


Position 
Controller 


Position Ctrl 
Supervisor 


Position Ctrl 
Supervisor 


Position Ctrl 
Supervisor 


Parameter 
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Data 
| Name | # | Number | Name | # |_—Type 
Position 25 nex 1-7 Enable 17 BOOL 
Controller 
Sick 1-7 Rev 51 BOOL 
Limit 
DD hex 1-7 Positive Limit | 56 BOOL 
Triggered 
25nhex 1-7 Negative 57 BOOL 
Limit 
Triggered 
2 hex 1-7 Following 47 BOOL 
Error Fault 
2Ghex Block Fault BOOL 
5hex 1-7 Load Data 58 BOOL 
Complete 
24nex Produced 33 USINT 
Axis Number 
4nex 1-7 Rspne 7 USINT 
Message Type 
25hex 1-7 Actual 13 DINT 
Position 
25 hex 1-7 Commanded 14 DINT 
Position 
25hex 1-7 Actual 15 DINT 
Velocity 
5 hex 1-7 Commanded 16 DINT 
Velocity 
: . pe 
24nex 1-7 Home 17 DINT 
Position 
24nex 1-7 Registration 24 DINT 
Position 
OF nex 1-255 Parameter 1 Determined 
Value by instance of 
parameter 
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6-19. 


6-19.1. 
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MOTOR OVERLOAD 
Device Type: 03hex 


The Motor Overload device profile is part of a “Hierarchy of Motor Control Devices” that are 
supported by CIP. This hierarchy includes: 


e Contactors, Overloads, and Across the Line Motor Starters 
e 6Softstarters 

e AC/DC Drives 

e Servo Drives 


Devices within this hierarchy use a common Control Supervisor object to control state behavior 
of the device. Devices within this hierarchy also support a hierarchy of “IO Assembly 
Instance” definitions which are used to pass control and status information to and from a 
device. Assembly instances are numbered so that each device type is assigned a range of 
instance numbers, with higher functionality devices supporting higher instance numbers. 
Devices within the hierarchy can choose to support some instance numbers that are lower than 
theirs in the hierarchy. For example, an AC Drive may choose to support some instances that 
are defined for Across the Line Motor Starters. This makes it easier to interchange drives and 
starters within a system. 


This profile makes Motor Starters of the same device type inter-operable, but not directly 
interchangeable without doing configuration through a unit’s local interface, a network 
configuration tool or other means of configuring outside the CIP interface. 


Object Model 
The Object Model in Figure 6-19.1 represents a Motor Overload. The table below indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Object Class Optional/Required # of Instances 


Identity 1 
Message Router 1 
Network Specific Link Object | Required 1 
Connection Required 2 
Assembly Optional 1 
Parameter - 
Control Supervisor Required 1 
Overload : 
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6-19.2. 


Release 1.0 


Figure 6-19.1. Object Model for a Motor Overload Device 
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How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Object Effect on behavior 
Identity Supports the Reset service 
Message Router No effect 
Network Specific Link | Configures port attributes 
Object 
Connection Logical ports into or out of the device 
Assembly Defines I/O data format 
Parameter Provides a public interface to device configuration data 
Control Supervisor Manages motor functions and operational states 
Overload Implements overload 
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6-19.3. 
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Defining Object Interfaces 


The objects in the Motor Overload have the interfaces listed in the following table: 


Object 
Identity 
Message Router 
Network Specific 
Link Object 
Connection 
Assembly 
Parameter 
Control Supervisor 


Overload 
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Interface 


Message Router 
Explicit Message Connection 


Message Router 


Message Router 
I/O Connection or Message Router 
Message Router 


Message Router, Assembly or Parameter Object 


Message Router, Assembly or Parameter Object 


Release 1.0 


Volume 1: CIP Common Specification Chapter 6: Device Profiles 


6-19.4. Contactor Interface and Behavior 


L1O <a. Tl 
L2 a O T2 
L3O ——- T3 


02-18 CurrentL1 
Ox2C-1-9 CurrentL2 
0x2C-1-10 CurrentL3 
[0x20-1-5] AveCurrent 
wt | nto ea aa 
% Thermal 

(rea) 


FaultRst a Vendor Specific (asi 
Local Fault Rst Reset Logic 


TRIP 


0x29-1-10 | Faulted/Trip 
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6-19.5. 


6-19.5.1 
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1/O Assembly Instances 


The IO Assembly Instance definitions in this section define the format of the “data” attribute 
(attribute 3) for IO Assembly Instances. Through the use of predefined instance definitions, IO 
Assemblies support a hierarchy of motor control devices. The device hierarchy includes motor 
starters, soft starters, AC and DC drives, and servo drives. Assembly Instances are numbered 
within the hierarchy so that each device type is assigned a range of Assembly Instance 
numbers, with higher functionality devices supporting higher instance numbers. Devices in the 
hierarchy can choose to support instance numbers that are lower than theirs in the 
hierarchy. For example a Softstart may choose to support some IO Assemblies that are 
defined for Overload. The following table shows the Assembly Instance numbering for the 
motor control device hierarchy. 


Profile I/O Type Instance 
Range 


Contactors, Overloads and | Output 1-19 
Starters 50-69 
AC/DC Drive 20-29 
70-79 
Servo Drive 30-49 


80-99 


The following IO Assembly Instances are defined for Overloads. 


Instance Name 


2 Basic Overload 
50 Basic Overload 


51 Extended Overload 


If a bit is not used in an IO Assembly, it is reserved for use in other Assemblies. Reserved bits 
in Output Assemblies are ignored by the consuming device. Reserved bits in Input Assemblies 
are set to zero by the producing device. 


Connection Paths to I/O Assembly Instances 


The IO Assembly Instances are chosen for IO Connections by setting the 
“produced_connection_path” (attribute 14) and “consumed_connection_path” (attribute 16) 
attributes in the appropriate connection object. 


Motor Control Devices use the Symbolic Segment Type (see Appendix C) to specify paths to 
the IO Assembly Instances in the Motor Control Hierarchy. IO Assembly Instances are 
represented by ASCII strings that contain the hex number of the Assembly Instance whose path 
is to be chosen. 
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The following example shows the Symbolic Segment used to specify Output Assembly 
Instance 20 (14 hex). 


01100010 00110001 00110100 


{ 
L 


segment symbol size in ASCII 1 (31 hex) ASCII 4 (34 hex) 
type bytes (2 bytes) 
(symbolic) 


6-19.6. I/O Assembly Data Attribute Format 
6-19.6.1. Output Assembly Data Attribute Format 


Instance 2: Basic Overload 
This is the only required output assembly for the device type Motor Overload (03hex) 


Byte Bit 1 Bit 
0 Reserved 


6-19.6.2. Input Assembly Data Attribute Format 


Instance 50: Basic Overload 
This is the only required input assembly for the device type Motor Overload.(03hex). 


Byte Bit] Bit 0 


Trip 


Instance 51: Extended Overload 
This assembly uses some optional attributes 


Byte Bit | Bit 0 
Trip 


6-19.7._ Mapping I/O Assembly Data Attribute Components 


6-19.7.1. Mapping for Output Assembly Data Components 
Attribute 


Data Name Class Name Class Instance Attribute 
Number Name Number 


6-19.7.2. Mapping for Input Assembly Data Components 


Data Name Class Name Class Instance Attribute Attribute 
Number Name Number 
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6-19.8. Defining Device Configuration 


Public access to the Control Supervisor Object and the Overload Object must be supported for 
configuration of a Motor Overload devices. If supported, optional Parameter Objects may be 


used to access the various configuration attributes in the Control Supervisor Object and the 
Overload Object. 
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6-20. WEIGH SCALE 


The profile for this device type will be defined by the Open DeviceNet Vendor Association, 
Inc.and ControlNet International. 
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6-21. ENCODER 


The profile for this device type will be defined by the Open DeviceNet Vendor Association, 
Inc. and ControlNet International. 
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6-22. RESOLVER 
Device Type: 09 hex 


A Resolver mechanically or otherwise detects the absolute position of a shaft. The position 
information is represented as a binary integer value. 


6-22.1. Object Model 
The Object Model in figure 6-22.1 represents a resolver. The table below indicates 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Chapter 5, The CIP Object Library, provides more details about these objects. 


Object Class Optional / Required # of Instances 


Network Specific Link Required 1 
Object 
Connection Required at least 1 I/O 
and 1 explicit 
Assembly Required at least 1 I/O input 
assembly 


Figure 6-22.1 Object Model for a Resolver 
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6-22.3. 


6-22.4. 
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How Objects Affect Behavior 


The objects in this device affect the device's behavior as shown in the following table. 


Object 
Identity 
Message Router 


Network Specific 
Link Object 


Connection 
Assembly 
Parameter 


Position Sensor 


Effect on Behavior 
Supports the reset service 
No effect 

Configures port attributes 


Contains the number of logical ports into or out of the device 
Defines I/O and/or configuration data format 

Provides a public interface to the device's configuration data 
Affects Value (attribute), Cam (attribute) 


Defining Object Interfaces 


The objects in this device have the interfaces listed in the following table. 


Object 
Identity 
Message Router 


Network Specific 
Link Object 


Connection 
Assembly 
Parameter 


Position Sensor 


Interface 
Message Router 
Explicit Messaging Connection Instance 


Message Router 


Message Router 
I/O Connection or Message Router 


Message Router 


Message Router, Assembly Object or Parameter Object 


1/O Assembly Instances 


The following table identifies the I/O assembly instance supported by the Resolver device. 


Number Required/Optional Name 


*At least 1 input assembly is required 
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6-22.5. I/O Assembly Data Attribute Format 
The I/O Assembly Data Attributes have the format shown below. 


Reserved (zero) 


Reserved (zero) 


6-22.6. Mapping I/O Assembly Data Attribute Components 


The following table indicates the I/O Assembly Data Attribute mapping for the Resolver 
device. 


Data Component Name Instance Attribute 
Number Number 


Value Position 23 ex 1 3 
Sensor 

CAM Position 23S tex 1 4 
Sensor 

SetZero Position 23 hex 1 SetZero 9 
Sensor 


6-22.7. Configuration Assembly Instances 


The following table identifies the configuration assembly instance supported by the Resolver 
device. 


Number Required/Optional Name 
W Without CAM 
a With CAM 
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6-22.8. Configuration Assembly Data Attribute Format 
The Configuration Assembly Data Attribute has the format shown below. 


40 [O Value Bit Resolution 


N 
@ 
[o) 
Q 
B 
oO 
e 


41 Value Bit Resolution 


Zero Offset 


CAM Low Limit 


CAM High Limit 


epee — nA]? R]wlrNMo]re KRW] NMR 
N]TRe|o 


6-22.9. Mapping Configuration Assembly Data Attribute Components 


The following table indicates the configuration Assembly Data Attribute mapping for the 
Resolver device. 


Data Component Name Instance Attribute 
Sensor i 
Zero Offset Position 2 Stiex 6 
ane 
Sensor 
Sensor 


6-22.10. Defining Device Configuration 


Public access to the Position Sensor Object by the Message Router must be supported for 
configuration of this device type. If supported, the optional Parameter Object may be used to 
access the device type's configuration parameters. 


If the Parameter Object is supported it must support a minimum of the Parameter Stub 
attributes, and may optionally support any or all of the Full Parameter Object attributes. 
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6-22.10.1. Parameter Object Instances 


The following table indicates the Parameter Object Instances supported by the Resolver device. 


Number Name 
1 Value Bit Resolution 
2 Zero Offset 
3 CAM Low Limit 
4 CAM High Limit 


6-22.10.2. Mapping Parameter Object Data 


The following table indicates the Parameter Object data mapping for the Resolver device. 


Configuration Parameter Class Instance Attribute 


Name Number Number 


CAM Low Limit 23h 1 CAM Low | 7 
Limit 

CAM High Limit 231%. 1 CAM High | 8 
Limit 


6-22.10.3. Configuration Parameter Definitions 


The following sections of an example EDS show the information necessary to define the 
configuration parameters for a Resolver device. 


[ParamClass] 
MaxInst=4 $Max Instances 
Descriptor=0x09 $Parameter Class Descriptor 
CfgAssembly=2 $Configuration Assembly Instance 
[Params] 
Param1= $Resolution parameter 
0, $Data placeholder 
6, "20 23 24 01 30 05", $Path size and path to attribute 
0x0000, $Descriptor 
8, 1, $Data type and size (USINT) 
"Bit Resolution", $Name 
"Bits", $Units 
ae $(not used) 
1, 32, (vendor specific), $Min, max and default values 
0, 0, 0, 0, 0, 0, 0, 0, 0; $(not used) 
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Param2= 
0, 
6, "20 23 24 01 30 06", 
0x0000, 
9,4, 
"Zero Offset", 


wt 
? 


wt 
? 


0, OxFFFFFFFF, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0; 


Param3= 
0, 
6, "20 23 24 01 30 07", 
0x0000, 
9, 4, 
"CAM Low Limit", 


wi 
? 


wit 
) 


0, OxFFFFFFFF, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0; 


Param4= 
0, 
6, "20 23 24 01 30 08", 
0x0000, 
9,4, 
"CAM High Limit", 


wt 
? 


wit 
? 


0, OxFFFFFFFF, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0; 
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$Zero Offset parameter 

$Data placeholder 

$Path size and path to attribute 
$Descriptor 

$Data type and size (UDINT) 
$Name 

$Units (none) 

$(not used) 

$Min, max and default values 
$(not used) 


$CAM Low Limit 

$Data placeholder 

$Path size and path to attribute 
$Descriptor 

$Data type and size (UDINT) 
$Name 

$Units (none) 

$(not used) 

$Min, max and default values 
$(not used) 


$CAM High Limit 

$Data placeholder 

$Path size and path to attribute 

$Descriptor 

$Data type and size (UDINT) 
$Name 

$Units (none) 

$(not used) 

$Min, max and default values 

$(not used) 


6-22.11. Effect of Configuration Parameters on Behavior 


The configuration parameters affect the device's behavior as shown below. 


Parameter 


Bit Resolution 
Sensor Object 


Zero Offset 
CAM Low 
CAM High 


Effect on behavior 


Sets the number of significant bits in the Value Attribute of the Position 


Sets the zero point for the Value Attribute of the Position Sensor Object 
Sets the low threshold for the CAM Attribute of the Position Sensor Object 
Sets the high threshold for the CAM Attribute of the Position Sensor Object 
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6-23. CONTROL STATION 


The profile for this device type will be defined by the Open DeviceNet Vendor Association, 
Inc. and ControlNet International. 
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6-24. MESSAGE DISPLAY 


The profile for this device type will be defined by the Open DeviceNet Vendor Association, 
Inc. and ControlNet International. 
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6-25. CIRCUIT BREAKER 


The profile for this device type will be defined by the Open DeviceNet Vendor Association, 
Inc. and ControlNet International. 
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6-26. Pneumatic Valve 


Device Type: 1B hex 


This Device Profile defines minimum requirements for a Pneumatic Valve Manifold with one 
or more solenoid points and ability to support optional discrete input points. 


6-26.1. Object Model 
The Object Model is illustrated in Figure 6-26.1 and the object classes are described in the 


following table: 
Object Classes Eon ID eT / Optional 
Identity | = Ox01l | 1 | Required | 


Message Router 


Network 0x03 Required 1 
Specific Link 
Object 


Assembly | or more * 
Connection 2 or more * 


ak 


Discrete Output 0x09 Required 1 or more * 
2K 


Parameter Vendor Specific 


* Depends on the level of I/O support provided by the product 
Discrete Input Class includes optional solenoid status points 
and/or optional discrete input points. 

*** Discrete Output Class includes the solenoid valve points. 
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CONTACTOR 
Device Type: 15hex 


The Contactor device profile is part of a “Hierarchy of Motor Control Devices” that are 
supported by CIP. This hierarchy includes: 


e Contactors, Overloads, and Across the Line Motor Starters 
e 6Softstarters 

e AC/DC Drives 

e Servo Drives 


Devices within this hierarchy use a common Control Supervisor object to control state behavior 
of the device. Devices within this hierarchy also support a hierarchy of “IO Assembly 
Instance” definitions which are used to pass control and status information to and from a 
device. Assembly instances are numbered so that each device type is assigned a range of 
instance numbers, with higher functionality devices supporting higher instance numbers. 
Devices within the hierarchy can choose to support some instance numbers that are lower than 
theirs in the hierarchy. For example, an AC Drive may choose to support some instances that 
are defined for Across the Line Motor Starters. This makes it easier to interchange drives and 
starters within a system. 


This profile makes Motor Starters of the same device type inter-operable, but not directly 
interchangeable without doing configuration through a unit’s local interface, a network 
configuration tool or other means of configuring outside the CIP interface. 

Object Model 

The Object Model in Figure 6-27.1 represents a Contactor. The table below indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Control Supervisor 


— 


Required 


Object Class # of Instances 
Message Router - 
Network Specific Link Object 1 
Connection 2 
Parameter - 
[Required | 
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Figure 6-27.1 Object Model for a Contactor Device 
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How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Object Effect on behavior 
Identity Supports the Reset service 
Message Router No effect 
Network Specific Link Configures port attributes 
Object 
Connection Logical ports into or out of the device 
Assembly Defines I/O data format 
Parameter Provides a public interface to device configuration data 
Control Supervisor Manages motor functions and operational states 
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6-27.3. Defining Object Interfaces 


The objects in the Contactor Device have the interfaces listed in the following table: 


Object Interface 
Identity Message Router 
Message Router Explicit Message Connection 
Network Specific Link | Message Router 
Object 
Connection Message Router 
Assembly 1/O Connection or Message Router 
Parameter Message Router 
Control Supervisor Message Router, Assembly or Parameter Object 
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6-27.4. Contactor Interface and Behavior 


Local Auto/Man Vendor Specific Net 
Net Control Logic 


Local Run | Vendor 
Specific 
Run Logic 


NET 


Run! 


Vendor Specific 
Fault Logic 


FLT 


P_— 0199-71-10 | Faulted 


M1 


PAA Sppa$a$pmpm Fr 07309-1-7_ | Running! 


NET 


H___| CtrlFromNet 


ESSE nena enna n ne anemone tin Honea Sauna naan tena em eee aes mee HAM aE NE aA Mae HOS maaan ee nena aaa n naan none ano e aM oe nen 
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1/O Assembly Instances 


The IO Assembly Instance definitions in this section define the format of the “data” attribute 
(attribute 3) for IO Assembly Instances. Through the use of predefined instance definitions, IO 
Assemblies support a hierarchy of motor control devices. The device hierarchy includes motor 
starters, soft starters, AC and DC drives, and servo drives. Assembly Instances are numbered 
within the hierarchy so that each device type is assigned a range of Assembly Instance 
numbers, with higher functionality devices supporting higher instance numbers. Devices in the 
hierarchy can choose to support instance numbers that are lower than theirs in the 
hierarchy. For example a Softstart may choose to support some IO Assemblies that are 
defined for Overload. The following table shows the Assembly Instance numbering for the 
motor control device hierarchy. 


Profile 1V/O Type Instance 
Range 


Contactors, Overloads and 1-19 
AC/DC Drive 20-29 
Servo Drive 30-49 


The following IO Assembly Instances are defined for Contactors. 


Name 


Basic Contactor 


Extended Contactor 


If a bit is not used in an IO Assembly, it is reserved for use in other Assemblies. Reserved bits 
in Output Assemblies are ignored by the consuming device. Reserved bits in Input Assemblies 
are set to zero by the producing device. 


Connection Paths to I/O Assembly Instances 


The IO Assembly Instances are chosen for IO Connections by setting the 
“produced_connection_path” (attribute 14) and “consumed_connection_path” (attribute 16) 
attributes in the appropriate connection object. 


Motor Control Devices use the Symbolic Segment Type (see Appendix C) to specify paths to 
the IO Assembly Instances in the Motor Control Hierarchy. IO Assembly Instances are 
represented by ASCII strings that contain the hex number of the Assembly Instance whose path 
is to be chosen. 
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The following example shows the Symbolic Segment used to specify Output Assembly 
Instance 20 (14 hex). 


01100010 00110001 00110100 


“fl 


segment symbol size in ASCII 1 (31 hex) ASCII 4 (34 hex) 
type bytes (2 bytes) 
(symbolic) 


6-27.6. I/O Assembly Data Attribute Format 


Instance 1: Basic Contactor 


This is the only required output assembly for device types Motor Contactor (0x1 5hex) and Softstart 
(0x15hex). 


Instance 4: Extended Contactor (See table for functional assignments) 
This assembly uses some optional attributes.. 


6-27.7. Mapping I/O Assembly Data Attribute Components 


The following table indicates the I/O Assembly Data Attribute mapping for Contactor Output 
Assemblies. 


Data Name Class Name Class Instance Attribute Attribute 
Number Name Number 


6-27.8. Defining Device Configuration 


Byte 


Public access to the Control Supervisor Object must be supported for configuration of 
Contactor devices. If supported, optional Parameter Objects may be used to access the various 
configuration attributes in the Control Supervisor Object. 
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MOTOR STARTER 
Device Type: 16hex 


The Motor Starter device profile is part of a “Hierarchy of Motor Control Devices” that are 
supported by CIP. This hierarchy includes: 


e Contactors, Overloads, and Across the Line Motor Starters 
e 6Softstarters 

e AC/DC Drives 

e Servo Drives 


Devices within this hierarchy use a common Control Supervisor object to control state behavior 
of the device. Devices within this hierarchy also support a hierarchy of “IO Assembly 
Instance” definitions which are used to pass control and status information to and from a 
device. Assembly instances are numbered so that each device type is assigned a range of 
instance numbers, with higher functionality devices supporting higher instance numbers. 
Devices within the hierarchy can choose to support some instance numbers that are lower than 
theirs in the hierarchy. For example, an AC Drive may choose to support some instances that 
are defined for Across the Line Motor Starters. This makes it easier to interchange drives and 
starters within a system. 


This profile makes Motor Starters of the same device type inter-operable, but not directly 
interchangeable without doing configuration through a unit’s local interface, a network 
configuration tool or other means of configuring outside the CIP interface. 

Object Model 

The Object Model in Figure 6-28.1. represents a Motor Starter. The table below indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Control Supervisor 


— 


Required 


Object Class # of Instances 
Message Router 1 
Network Specific Link Object 1 
Connection 2 
Parameter - 
[Required | 
[Required | 


Overload Required 
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Figure 6-28.1. Object Model for Motor Starter Device 
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6-28.2. How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Object Effect on behavior 
Identity Supports the Reset service 
Message Router No effect 
Network Specific Link | Configures port attributes 
Object 
Connection Logical ports into or out of the device 
Assembly Defines I/O data format 
Parameter Provides a public interface to device configuration data 
Control Supervisor Manages motor functions and operational states 
Overload Implements overload 
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6-28.3. Defining Object Interfaces 
The objects in the Motor Overload have the interfaces listed in the following table: 


Object Interface 
Identity Message Router 
Message Router Explicit Message Connection 
Network Specific Link | Message Router 
Object 
Connection Message Router 
Assembly 1/O Connection or Message Router 
Parameter Message Router 
Control Supervisor Message Router, Assembly or Parameter Object 
Overload Message Router, Assembly or Parameter Object 
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Local Auto/ManQ Vendor Specific NCI 
Net Control Logic 


Local Run 1 Vendor 
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6-114 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification 


6-28.3.2 Reversing Motor Starter Interface and Behavior 


Release 1.0 
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Vendor Specific 
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MI 
0x29-1-7 |Running] 


M2 


P7120 Running2 
FLT TRIP 
0x29-1-9 


Ready 


NET 
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CtrlFromNet 


Chapter 6: Device Profiles 


6-115 


Chapter 6: Device Profiles Volume 1: CIP Common Specification 


6-28.3.3 Two Speed Motor Starter Interface and Behavior 


Vendor 


Local Run 1 
Specific 


Local Run 2 6 
NET 
NET 
M1 (Slow) 
CY Tl-1 
(YY O T2-1 
ner an 


CY _Y T1-2 


ies aoe 
ieee ae 
eee 3 


M2 (Fast) 0x2C-1-8 | CurrentL1 


Ox2C-1-9 |CurrentL2 
i ae cn 


E 0x2C-2-8 | CurrentL1 
Pa 0x2C-2-10 |CurrentL3 
Overload 0x2C-2-5_ | AvgCurrent 
Protection 0x2C-2-6 _|%PhImbal 


Function 


(Fast) aoe | 0x2C-2-7_|% Thermal 
YA H 


Overload 0x2C-1-5_ | AvgCurrent 
aSe Protection | cae] osphtibal 
Function : 


se — 0 er. 
Fault ea el Vendor Specific 
Local Fault Rst OE Reset Logic (xsi) 
Vendor Specific 
Fault Logic @ 
| O_o 
H = (ver) 
NetCtrl | 0x29-1-5 0 |efecvvnn 
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6-28.4. 


Release 1.0 


Warning 


Vendor Specific 
Warning Logic 


FLT 


Faulted 


TRP1 


TRP2 


| 0x29-1-7_|Running1 


M2 


-|_0x29-1-8 Running? 


FLT TRP1 TRP2 


Ready 


NET 


CtrlFromNet 


ee cr 


I/O Assembly Instances 


The IO Assembly Instance definitions in this section define the format of the “data” attribute 
(attribute 3) for IO Assembly Instances. Through the use of predefined instance definitions, IO 
Assemblies support a hierarchy of motor control devices. The device hierarchy includes motor 
starters, soft starters, AC and DC drives, and servo drives. Assembly Instances are numbered 
within the hierarchy so that each device type is assigned a range of Assembly Instance 
numbers, with higher functionality devices supporting higher instance numbers. Devices in the 
hierarchy can choose to support instance numbers that are lower than theirs in the 
hierarchy. For example a Softstart may choose to support some IO Assemblies that are 
defined for Overload. The following table shows the Assembly Instance numbering for the 
motor control device hierarchy. 
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Profile 
Contactors, Overloads and 
Starters 


AC/DC Drive 


Servo Drive 


The following IO Assembly Instances are defined for Motor Starters. 


Instance 
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I/O Type 


Name 


Output Basic Motor Starter 


& 


Output 


Extended Contactor 


Extended Motor Starter 


52 Basic Motor Starter 
53 Extended Motor Starter | 


Instance 
Range 


54 Extended Motor Starter 2 


If a bit is not used in an IO Assembly, it is reserved for use in other Assemblies. Reserved bits 
in Output Assemblies are ignored by the consuming device. Reserved bits in Input Assemblies 
are set to zero by the producing device. 


6-28.4.1. Connection Paths to I/O Assembly Instances 


The IO Assembly Instances are chosen for IO Connections by setting the 
“produced_connection_path” (attribute 14) and ““consumed_connection_path” (attribute 16) 
attributes in the appropriate connection object. 


Motor Control Devices use the Symbolic Segment Type (see Appendix C) to specify paths to 
the IO Assembly Instances in the Motor Control Hierarchy. IO Assembly Instances are 
represented by ASCII strings that contain the hex number of the Assembly Instance whose path 
is to be chosen. 


The following example shows the Symbolic Segment used to specify Output Assembly 
Instance 20 (14 hex). 


01100010 00110001 00110100 


ASCII 1 (31 hex) ASCII 4 (34 hex) 


a 


segment 
type 
(symbolic) 


symbol size in 
bytes (2 bytes) 
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6-28.5. I/O Assembly Data Attribute Format 
6-28.5.1 Output Assembly Data Attribute Format 


Instance 3: Basic Motor Starter 
This is the only required output assembly for device type Motor Starter (1 6hex) 


0 Reserved _| Runl 


Instance 4: Extended Contactor (see table for functional assignments) 
This assembly uses some optional attributes.. 


0 Run] 


Instance 5: Extended Motor Starter (see table for functional assignments) 
This assembly uses some optional attributes.. 


0 Runl 
6-28.5.2 Input Assembly Data Attribute Format 


Instance 52: Basic Motor Starter 


This is the only required input assembly for Motor Starter (16hex) 


Trip 


Instance 53: Extended Motor Starter 1 (see table for functional assignments) 


This assembly uses some optional attributes 


Net Trip 


Instance 54: Extended Motor Starter 2 (see table for functional assignments) 


This assembly uses some optional attributes 


Net Trip 


6-28.6. Mapping I/O Assembly Data Attribute Components 
6-28.6.1. Mapping for Motor Starter Output Assembly Data Components 


Name 
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6-28.6.2. 


6-28.7. 


6-120 


Mapping for Motor Starter Input Assembly Data Components 


Data Class Name Class Number | Instance |} Attribute Name | Attribute Number 
Name 
Trip 


= 


Control Control Supervisor 0x29 1 CtrlFromNet 15 
From Net 


Defining Device Configuration 


Public access to the Control Supervisor Object and the Overload Object must be supported for 
configuration of Motor Starter devices. If supported, optional Parameter Objects may be used 
to access the various configuration attributes in the Control Supervisor Object and the Overload 
Object. 
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6-29. SOFTSTART STARTER 
Device Type: 17hex 


The Softstart Starter device profile is part of a “Hierarchy of Motor Control Devices” that are 
supported by CIP. This hierarchy includes: 


e Contactors, Overloads, and Across the Line Motor Starters 
e 6Softstarters 

e AC/DC Drives 

e Servo Drives 


Devices within this hierarchy use a common Control Supervisor object to control state behavior 
of the device. Devices within this hierarchy also support a hierarchy of “IO Assembly 
Instance” definitions which are used to pass control and status information to and from a 
device. Assembly instances are numbered so that each device type is assigned a range of 
instance numbers, with higher functionality devices supporting higher instance numbers. 
Devices within the hierarchy can choose to support some instance numbers that are lower than 
theirs in the hierarchy. For example, an AC Drive may choose to support some instances that 
are defined for Across the Line Motor Starters. This makes it easier to interchange drives and 
starters within a system. 


This profile makes Softstart Starters of the same device type inter-operable, but not directly 
interchangeable without doing configuration through a unit’s local interface, a network 
configuration tool or other means of configuring outside the CIP interface. 


6-29.1. Object Model 
The Object Model in Figure 6-29.1 represents a Softstart Starter. The table below indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Object Class # of Instances 
Message Router 1 
Network Specific Link Object 1 
Connection 2 
Control Supervisor 1 
[Optional 


Motor Data Optional 
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6-122 


Figure 6-29.1. Object Model for Softstart Starter Device 


Parameter 


Application 
TRP2 


Control 
Supervisor 


Message Router 


Assembly 


Input 
Instance 
M1 


Output 
Instance 
FLT 


Network Specific 
Link Object 


I/O Data Explicit) 
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How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Object 


Identity 
Message Router 


Network Specific Link 
Object 


Connection 
Assembly 
Parameter 

Control Supervisor 


Softstart 


Overload 


Motor Data 


Effect on behavior 


Supports the Reset service 
No effect 


Configures port attributes 


Logical ports into or out of the device 

Defines I/O data format 

Provides a public interface to device configuration data 
Manages motor functions and operational states 
Implements the Softstart 

functions 

Implements overload 


Define motor data for motor connected to this device. 


Defining Object Interfaces 


The objects in the Motor Overload have the interfaces listed in the following table: 


Object 


Identity 
Message Router 


Network Specific Link 
Object 


Connection 
Assembly 
Parameter 

Control Supervisor 
Softstart 

Overload 


Motor Data 
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Interface 


Message Router 
Explicit Message Connection 


Message Router 


Message Router 

I/O Connection or Message Router 

Message Router 

Message Router, Assembly or Parameter Object 
Message Router or Assembly 


Message Router, Assembly or Parameter Object 


Message Router, Parameter Object 
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6-29.4. Softstart Motor Interface and Behavior 


Local Run 1 
Vendor 
Specific 


Local Run 2 O Run Logic 
NET 
Run 


NET 


0 CY Tl 
Sas: 
L3 fe) cy’ T3 


0x2C-1-8 | CurrentL1 
0Ox2C-1-9 |CurrentL2 
0x2C-1-10 |CurrentL3 
Ox2C-1-5 
Overload AvgCurrent 
RST and 0x2C-1-6 |%PhImbal 


Protection 


Function Ox2C-1-7 |%Thermal 


(x) 


Pauls Eo Vendor Specific 
Local Fault Rst Reset Logic 
Vendor Specific 
Fault Logic 


NetCtrl | Ox29-1-5 [few 
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Vendor Specific 
Warning Logic 


Warning 


Faulted 


Ml 
PWAA Ff 0x229-1-7_ | Running! 
M2 


SS en 1-8 |Running2 


FLT TRIP 


NET 


J_ 5 J cere 
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6-29.5. 


6-29.5.1. 


6-126 


1/O Assembly Instances 


The IO Assembly Instance definitions in this section define the format of the “data” attribute 
(attribute 3) for IO Assembly Instances. Through the use of predefined instance definitions, IO 
Assemblies support a hierarchy of motor control devices. The device hierarchy includes motor 
starters, soft starters, AC and DC drives, and servo drives. Assembly Instances are numbered 
within the hierarchy so that each device type is assigned a range of Assembly Instance 
numbers, with higher functionality devices supporting higher instance numbers. Devices in the 
hierarchy can choose to support instance numbers that are lower than theirs in the 
hierarchy. For example a Softstart may choose to support some IO Assemblies that are 
defined for Overload. The following table shows the Assembly Instance numbering for the 
motor control device hierarchy. 


Profile 1/O Type Instance 
Range 


Contactors, Overloads and 1-19 
Starters [Te 
AC/DC Drive 20-29 
Servo Drive 30-49 
30-9 


The following IO Assembly Instances are defined for Softstarters. 


Instance Name 
60 Basic SoftStart 
61 Extended SoftStart 


Connection Paths to I/O Assembly Instances 


The IO Assembly Instances are chosen for IO Connections by setting the 
“produced_connection_path” (attribute 14) and “consumed_connection_path” (attribute 16) 
attributes in the appropriate connection object. 


Motor Control Devices use the Symbolic Segment Type (see Appendix C) to specify paths to 
the IO Assembly Instances in the Motor Control Hierarchy. IO Assembly Instances are 
represented by ASCII strings that contain the hex number of the Assembly Instance whose path 
is to be chosen. 


The following example shows the Symbolic Segment used to specify Output Assembly 
Instance 20 (14 hex). 


01100010 00110001 001104100 


Segment Type Symbolic size in ASCI 1 ASCII 4 
(Symbolic) bytes (2 bytes) (31 hex) (34 hex) 


L 
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6-29.6. 
6-29.6.1. 


6-29.6.2. 


6-29.7. 


6-29.8. 


Release 1.0 


I/O Assembly Data Attribute Format 
Output Assembly Data Attribute Format 


There are no new output assemblies defined for SoftStart devices. 


Input Assembly Data Attribute Format 
Instance 60: Basic SoftStart Input 


This is the only required input assembly. for the device type SoftStart (15hex) 


0 At Reserved | Reserved Reserved | Reserved | Running! | Reserved | Faulted/ 
Reference Trip 


Instance 61: Extended SoftStart Input (see table for functional assignments) 


This assembly uses some of the optional attributes. 


At Reserved | CntrlfromNet | Ready Running2 | Running! | Warning | Faulted/ 
Reference Trip 
Data Name Class Name Class Instance | Attribute Attribute 
Number Name Number 


Defining Device Configuration 


Public access to the Control Supervisor Object and the Overload Object must be supported for 
configuration of Softstart devices. If supported, optional Parameter Objects may be used to 
access the various configuration attributes in the Control Supervisor Object and the Overload 
Object. 
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6-30. HUMAN-MACHINE INTERFACE (HMI) 
Device Type: 18hex 


The Human-Machine Interface (HMI) Device type is based on the Generic Device Type 
(OOhex). The purpose of this device profile is to allow network tools to identify and distinguish 
HMI devices from other Generic devices on a network. Over time, the and ControlNet 
International and Open DeviceNet Vendor Association’s HMI Special Interest Groups (SIG) 
will enhance the HMI device profile to define minimum required objects and optional objects 
which are similar among HMI devices. HMI Device type devices are not interchangeable. 


6-30.1. Object Model 


The Object Model in Figure 6-30.1. represents the minimum support in an HMI Device. The 
table below indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Object Class # of Instances 
Identity at least 1 
Message Router 1 
Network Specific Link Object at least 1 


Connection Required at least 1 I/O 
and | explicit 
Application at least 1 


The HMI Device profile cannot specify the definition of the Assembly Object or the type of 
application objects necessary for device operation. This portion of the device profile must be 
supplied by the product developer as described in Chapter 2, Contents of a Device Profile. 
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Figure 6-30.1. Object Model for an HMI Device 


Application Objects 


Identity Object 


Message Router 


Assembly Object ) 


Explicit 
Msg. 


Connection Class 


DeviceNet 
Object 


DeviceNet Network 


6-30.2. How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Object Effect on behavior 
Identity Supports the Reset service 
Message Router No effect 
Network Specific Link Object | Configures port attributes (node address, data rate, and BOT) 
Connection Class Contains the number of logical ports into or out of the device 
Assembly Defines input/output and configuration data format 
Application Defines device operation 


6-30.3. Defining Object Interfaces 
The objects in the HMI Device have the interfaces listed in the following table: 
Object Interface 
Identity Message Router 
Message Router Explicit Messaging Connection Instance 


Network Specific Link Object | Message Router 


Connection Class Message Router 
Assembly I/O Connection or Message Router 
Application Assembly or Message Router 
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6-31. 


6-31.1. 


6-130 


MASS FLOW CONTROLLER DEVICE 


Device Type: 1Anex 


A Mass Flow Controller is a device that measures and controls the mass flow rate of gas or 
liquid. It contains three principle components: a mass flow rate sensor which can be one of a 
variety of types, including thermal or pressure-based; a mass flow rate metering valve which 
can be actuated by one of a variety of actuator types, including solenoid, voice coil or piezo; 
and, a controller which closes the loop by receiving a setpoint and driving the actuator such 
that the mass flow rate is controlled to the setpoint. 


Object Model 


The Object Model in Figure 6-31.1. represents a Mass Flow Controller Device. The table below 
indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Object Class Optional/Required # of Instances 


Message Router 1 

Network Specific Link Object 1 

Connection at least 1 I/O and 1 Explicit 
Assembly at least 1 Input and 1 Output 
S-Device Supervisor 1 

S-Gas Calibration 0 or More 

S-Analog Sensor 1 

S-Analog Actuator 1 

S-Single Stage Controller 1 


* Required for a Mass Flow Controller, a device that contains a Valve 
and a Controller. Not supported in a Mass Flow Meter Device (an MFC 
without a Valve or a Controller). 


Class Subclasses 


Each class level subclass defines a unique meaning for an overlapping range of class attribute 
IDs and/or class service IDs. The range for subclass definitions begins at ID 96 and numbers 
downward for attributes, and ID 63,,, and numbers downward for services. The subclass for a 
given class is identified by the value of its Subclass class attribute. There are no class level 
subclasses specified for this device. 
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Instance Subclasses 


Each instance level subclass defines a unique meaning for an overlapping range of instance 
attribute IDs and/or instance service IDs. The range for subclass definitions begins at ID 96 
and numbers downward for attributes, and ID 63), and numbers downward for services. The 
subclass for a given instance is identified by the value of its Subclass instance attribute. The 
following tables identify which object instance IDs are assigned subclasses for this device. 


S-Analog Sensor Object Subclasses 


Instance Subclass Name Subclass ID | Required Function Restrictions 
ID (Attribute 
99 Value) 


1 Flow Diagnostics 01 Required Added diagnostics | None 
for MFC 


S-Gas Calibration Object Subclasses 


Instance Subclass Name Subclass ID | Required Function Restrictions 
ID (Attribute 
99 Value) 


1 Standard T & P 01 Optional Standard None 
Temperature and 
Pressure 


Figure 6-31.1. Object Model for the MFC Device 
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6-31.3. 


6-31.4. 
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How Objects Affect Behavior 


Object 
Identity 


Message Router 


Network Specific Link 
Object 


Connection Class 
Assembly 


S-Device Supervisor 


S-Gas Calibration 


S-Analog Sensor 
S-Single Stage Controller 
S-Analog Actuator 


Effect on behavior 
Supports the Reset service. Upon receipt of a Reset Service Request of any Type, the 
Identity Object sends a Reset Service Request to the S-Device Supervisor. 
No effect 


Configures port attributes (node address, data rate, and BOI) 


Contains the number of logical ports into or out of the device 
Defines input/output and configuration data format 


Supports the Stop, Start, Reset, Abort, Recover and Perform Diagnostic services for 
ALL Application Objects in the device and consolidates the Exception Conditions 
and Application Objects’ Status. 


This object behaves differently from the Identity Object in that the S-Device 
Supervisor object provides a single point of access to the Application Objects only; it 
does not effect the CIP specific objects (i.e., Identity, Network Specific Link Object, 
Connection, etc.). 


Modifies the correction algorithm of the S-Analog Sensor object which includes the 
selection mechanism to enable an S-Gas Calibration object instance. 


Feeds the process variable to the Single Stage Controller object 
Feeds the control variable to the Analog Actuator object 


Operates the Flow Control Valve of the device 


Defining Object Interfaces 


Object 
Identity 
Message Router 


Network Specific Link 
Object 


Connection Class 
Assembly 

S-Device Supervisor 
S-Gas Calibration 
S-Analog Sensor 
S-Single Stage Controller 
S-Analog Actuator 


Interface 
Message Router 
Explicit Messaging Connection Instance 


Message Router 


Message Router 

I/O Connection or Message Router 
Assembly or Message Router 
Message Router 

Assembly or Message Router 
Assembly or Message Router 
Assembly or Message Router 


I/O Assembly Instances 


The following table identifies the I/O assembly instances supported by the MFC. 


Y (default) Status and Flow 


N 
N 
Y 


HDi np] wl nite 


Status, Flow and Valve 

Status, Flow, and Setpoint 

Status, Flow, Setpoint and Valve 

Status, Flow, Setpoint, Override and Valve 
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6-31.5. 


Release 1.0 


oe = 
| 


1/O Assembly Object Instance Data Attribute Format 


Chapter 6: Device Profiles 


The manufacturer of a Mass Flow Controller Device must specify which Assembly instances 


are supported by the device. 


The I/O Assembly DATA attribute has the format shown below. 


wma] we [ee [ws [a [ws [we [av 
1 lo | Flow (low byte) 
Flow (high byte) 
2 lo | Status 
Flow (low byte) 
Flow (high byte) 
3 lo | Status 
Flow (low byte) 
Flow (high byte) 
Valve (low byte) 
Valve (high byte) 
4 | 0 | Status 
Flow (low byte) 
Flow (high byte) 
Setpoint (low byte) 
Setpoint (high byte) 
5 | 0 | Status 
Flow (low byte) 
Flow (high byte) 
Setpoint (low byte) 
Setpoint (high byte) 
5 Valve (low byte) 
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sce [wes [ae [as [wo 


Valve (high byte) 

6 = Status 
Flow (low byte) 
Flow (high byte) 
Setpoint (low byte) 
Setpoint (high byte) 
Override 
| 6 | Valve (low byte) 
Valve (high byte) 

7 Or Setpoint (low byte) 
Setpoint (high byte) 

8 | oo | Override 
Setpoint (low byte) 
Setpoint (high byte) 

9 Lo | Status 

10 | oo | Status 
Exception Detail Alarm 0 (size, common) 
Exception Detail Alarm 1 (common 0) 
Exception Detail Alarm 2 (common 1) 
Exception Detail Alarm 3 (size, device) 
Exception Detail Alarm 4 (device 0) 
Ea Exception Detail Alarm 5 (size, manufacturer) 
Exception Detail Alarm 6 (manufacturer 0) 

11 = 50> = | Status 
Exception Detail Warning 0 (size, common) 
Exception Detail Warning 1 (common 0) 
Exception Detail Warning 2 (common 1) 
Exception Detail Warning 3 (size, device) 
Exception Detail Warning 4 (device 0) 
Es Exception Detail Warning 5 (size, manufacturer) 
Exception Detail Warning 6 (manufacturer, 0) 

12 Ew Status 
Exception Detail Alarm 0 (size, common) 
Exception Detail Alarm 1 (common 0) 
Exception Detail Alarm 2 (common 1) 
Exception Detail Alarm 3 (size, device) 
Exception Detail Alarm 4 (device 0) 
| 6 | Exception Detail Alarm 5 (size, manufacturer) 
Exception Detail Alarm 6 (manufacturer, 0) 
8 | Exception Detail Warning 0 (size, common) 
| 9 | Exception Detail Warning 1 (common 0) 
Exception Detail Warning 2 (common 1) 
Exception Detail Warning 3 (size, device) 
Exception Detail Warning 4 (device 0) 
Exception Detail Warning 5 (size, manufacturer) 
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mc [om [ms [oe [os [os [os [a 


13 


14 


15 


16 


17 


Release 1.0 


Exception Detail Warning 6 (manufacturer, 0) 
Hh (low byte) 


Flow 


Flow (high byte) 


Status 
Flow (low byte) 


Flow 


Flow 


Flow (high byte) 
Status 

Flow (low byte) 

Flow 


Flow (high byte) 


Valve (low byte) 
6 | Valve 


Valve 
Valve (high byte) 


0 | Status 
Flow (low byte) 


Flow 
Flow 


Flow (high byte) 
Setpoint (low byte) 


Setpoint 
Setpoint 


8 | Setpoint (high byte) 
lo | Status 

Flow (low byte) 
Flow 

Flow 

Flow (high byte) 
Setpoint (low byte) 
lo | Setpoint 
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6-31.6. 


Instance 


18 


19 


20 


Setpoint 


[8 _| Setpoint (high byte) 
9 | Valve (low byte) 
Valve 

Valve 

Valve (high byte) 
lo | Status 

Flow (low byte) 
Flow 

Flow 

Flow (high byte) 
Setpoint (low byte) 
lo | Setpoint 

Setpoint 

[8 _ | Setpoint (high byte) 
9 | Override 

Valve (low byte) 
Valve 

Valve 

Valve (high byte) 
lo | Setpoint (low byte) 
Setpoint 

Setpoint 

Setpoint (high byte) 
lo | Override 

Setpoint (low byte) 
Setpoint 

Setpoint 


Setpoint (high byte) 
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rr [we [ows oes [oes [2 [a mo 


Mapping I/O Assembly Data Attribute Components 


Each of the S-Analog Sensor, S-Analog Actuator and S-Single Stage Controller object 
definitions specifies a behavior that modifies the Data Type of certain attributes based upon the 
first valid I/O connection established to an Assembly Object instance. In order to maintain 
consistency, this device type will only allow connections to either INT or REAL based 
Assembly instances. Once a valid connection is established, attempts to configure connections 
to a different type of Assembly instance will return an error. 


The following table indicates the I/O assembly Data attribute mapping for this MFC device. 


Data Component Instance} Attribute 
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6-31.7.1. 


Release 1.0 


Name | Name | | Number Number | Name | | Number Type 


Flow S-Analog Sensor 31 hex Indicated INT 
Flow 

is emcee pf ae 

Override S- }S-Analog Actuator | Actuator ee ae ee [5 USINT 


Setpoint S- ene Stage 33hex Setpoint “ae 
Controller 
Status S-Device Supervisor | 30hex Exception BYTE 
Status 
Exception Detail S-Device Supervisor | 30hex 1 Exception STRUCT 
Alarm Detail Alarm 


Exception Detail S-Device Supervisor | 30hex 1 STRUCT 
Warning i 
FP-Flow S-Analog Sensor 31 hex 1 Indicated REAL 
Flow 
FP-Setpoint S-Single Stage 33hex 1 Setpoint REAL 
Controller 


Object Limitations and Specific Definitions 


This section describes limitations and specific definitions applicable to the listed objects of this 
device profile when these objects are applied in this type of device. 


S-DEVICE SUPERVISOR OBJECT INSTANCE 


Limitations 


Attribute Limitation 


Supported Values: 
“MFC” = Mass Flow Controller device 
“MFM” = Mass Flow Meter device 


Device Type 


Specific Definition 


The following table specifies the data attribute bit mapping for the Device Exception Detail 
bytes for this MFC device. For more descriptive information, see the definition of the S- 
Device Supervisor Object Class. Noted, for each entry, is the Object from which the Status 
byte/bit is mapped. See the object specification for the detailed bit mapping. 
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Any Exception Bit not supported must default to 0. Note that this profile allows for only one 
byte of manufacturer specific exception detail. 


Data Bit eal Bit al Bit 5 Bit 4 Bit 3 Ea 2 ees 1 Bit 0 
Component 
MFC Device 
Exception Detail 
Size 


MFC Device a ie Valve Flow Flow Flow Reading 
Exception Detail High Control High Low Valid 
S-Analog | S-Analog | S-Single | S-Analog | S-Analog 
Actuator Sensor Sensor S-Analog 
Controller Sensor 


Manufacturer 
Exception Detail 
Size 


Manufacturer 8 Bits defined by Manufacturer 
Exception Detail 


* Only used in the Warning Exception Detail, this bit is always = 0 in the Alarm Exception 
Detail. 
6-31.7.2. S-ANALOG SENSOR OBJECT 


Limitations 


t 


Data Type Supported Values = {INT; REAL} Supported Values = {INT; REAL} INT 


Data Units Supported Values = {Counts & Units Supported Values = {Counts; Counts 
of the Flow Group} (see Appendix K) sccm} 


Offset-A Supported Values = {INT; REAL} Supported Values = {INT; REAL} INT 
Data Type 

Gain Data Supported Values = {INT; REAL} Supported Values = {INT; REAL} INT 
Type 


6-31.7.3. S-ANALOG ACTUATOR OBJECT 
Limitations 


Data Type Supported Values = {INT; REAL} Supported Values = {INT; REAL} INT 


Data Units Supported Values = {Counts, %, Supported Values = {Counts; %} Counts 


Voltage, Current & Units of the Flow 
Group} (see Appendix K) 


Gain Data Supported Values = {INT; REAL} Supported Values = {INT; REAL} INT 
Type 
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6-31.8. 
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S-SINGLE STAGE CONTROLLER OBJECT 


Limitations 


Attribute 


Data Type 
Data Units 


Process 
Variable 


CV Data 
Type 
Control 
Variable 


Supported Values = {INT; REAL} Supported Values = {INT; REAL} INT 


Supported Values = {Counts, %, Supported Values = {Counts; %} Counts 
Voltage, Current & Units of the Flow 
Group} (see Appendix K) 


Not accessible over the network. The A. N.A. 
Process Variable input to this object 

instance is the value of the S-Analog 

Sensor object instance Value attribute. 


Not accessible over the network, The N.A. N.A. 
Control Variable output from this 

object is the value of the S-Analog 

Actuator object instance Value 

attribute. 


Defining Device Configuration 


Public access to the S-Device Supervisor, S-Analog Sensor, S-Analog Actuator, S-Single Stage 
Controller, and S-Gas Calibration Objects by the Message Router must be supported for 
configuration of this device type. 
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VACUUM / PRESSURE GAUGE DEVICE 
Device Type: 1Chex 


The objective of this profile is to provide a vacuum or pressure measurement profile which is 
inclusive of all technologies used to provide the pressure reading. By use of gauge” 
subclasses of the S-Analog Sensor, this profile can apply to Heat Transfer Gauges (Convection, 
Pirani, Thermocouple), Hot Cathode Ion Gauge, Cold Cathode Ion Gauge or a Diaphragm 
Gauge. The gauge subclasses provide calibration, control and status attributes unique to each 
gauge type. The S-Analog Sensor Object provides a pressure value to the Assembly instances 
delineated in this profile. 


Combination and Multiple Gauges 


This profile has been structured to facilitate use of *Combination” gauges - multiple gauges 
each covering separate, contiguous ranges of pressure, only one gauge active and providing one 
Pressure Value at any particular time; and Multiple” gauges — in which all gauge readings are 
simultaneously available (but not necessarily valid). In both cases, multiple instances of the S- 
Analog Sensor Object are used. 


Object Model 
The Object Model in Figure 6-32.1 represents a Vacuum/Pressure Gauge Device. 


The table below indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Object Class # of Instances 
Connection At least 1 I/O polled and 1 Explicit. 
Assembly At least 1 Input 
S-Device Supervisor 1 


S-Analog Sensor 1 Subclass required as a minimum 1 or more 


See S-Analog Sensor Subclasses in object 
model above. 


S-Gas Calibration 1 or more 
Discrete Output Point 1 or more 
Analog Output Point 1 or more 
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Class Subclasses 


Each class level subclass defines a unique meaning for an overlapping range of class attribute 
IDs and/or class service IDs. The range for subclass definitions begins at ID 96 and numbers 
downward for attributes, and ID 63), and numbers downward for services. The subclass for a 
given class is identified by the value of its Subclass class attribute. 


S-Analog Sensor Class Level Object Subclasses 


ep eantis Subclass Name Subclass ID | Required Function Restrictions 
(Attribute 
99 Value) 


Class | Instance Selector 01 Required Data Flow from None 
the Active Instance 


Instance Subclasses 


Each instance level subclass defines a unique meaning for an overlapping range of instance 
attribute IDs and/or instance service IDs. The range for subclass definitions begins at ID 96 
and numbers downward for attributes, and ID 63,,., and numbers downward for services. The 
subclass for a given instance is identified by the value of its Subclass instance attribute. The 
following tables identify which object instance IDs are assigned subclasses for this device. 


S-Analog Sensor Object Instance Level Subclasses 


Bons Subclass Name Subclass ID Required Function Restriction 
(Attribute 99 Ss 
Value) 


Heat Transfer Conditional ** | Gauge ae | None 
Vacuum Gauge 


Diaphragm Gauge Conditional ** | Gauge Application aa 
Gauge 

™ Cold Cathode Ion 04 Conditional ** | Gauge Application | None 
Gauge 

* Hot Cathode Ion 05 Conditional ** | Gauge Application | None 
Gauge 


* Instance IDs are vendor specific 
** The Gauge type Subclass is required if the referenced gauge type is implemented. 
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Figure 6-32.1. Object Model. 


Hierarchy of Semiconductor 
Equipment Device Objects 


S-Analog Sensor 


S-Gas 
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- Capacitance Manometer 
- Cold Cathode lon 
- Hot Cathode lon 
- Heat Transfer 


Point 
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Message 
Router 
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Message 
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How Objects Affect Behavior 


Object 
Identity 


Message Router 
Link Specific 
Connection Class 
Assembly 


S-Device Supervisor 


S-Analog Sensor 


S-Gas Calibration 


Trip Point 


Discrete Output Point 
Analog Output Point 


Effect on behavior 


Supports the Reset service. Upon receipt of a Reset Service 
Request of any Type, the Identity Object sends a Reset Service 
Request to the S-Device Supervisor. 


No effect 

Configures port attributes 

Contains the number of logical ports into or out of the device 
Defines input/output and configuration data format 


Supports the Stop, Start, Reset, Abort, Recover and 
Perform_Diagnostic services for ALL Application Objects in the 
device and consolidates the Exception Conditions and Application 
Objects’ Status. 


This object behaves differently from the Identity Object in that the 
S-Device Supervisor object provides a single point of access to the 
Application Objects only; it does not effect the DeviceNet objects 
(i.e., Identity, DeviceNet, Connection, etc.). 


Each instance of this object provides a calibrated pressure value 
from a pressure transducer. This object can also be used to supply 
an internal potentiometer position used for calibration purposes. 
Each instance will most likely use a gauge subclass; which 
subclass is used is determined by the gauge technology used. 


Modifies the correction algorithm of the S-Analog Sensor object. 
The Gas Calibration Instance attribute of that object specifies 
which instance 1s active. 


Provides a process trip point comparator for the S-Analog Sensor 
value. Each instance is linked to an S-Analog Sensor instance. 
The output of this object may be used to drive the Discrete Output 
Point object. 


Reflects status of Trip Point object instances. 


Provides an Analog Output from the device which is fed from the 
S-Analog Sensor value. This analog value may be of a data type 
and data units different from those of the S-Analog Sensor. This 
object is required only if the output value is supported as visible to 
the network. 
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Defining Object Interfaces 


Object Interface 

Identity Message Router 
Message Router Explicit Messaging Connection Instance 
Link Specific Message Router 
Connection Class Message Router 
Assembly I/O Connection or Message Router 
S-Device Supervisor Assembly or Message Router 
S-Analog Sensor Assembly or Message Router 
S-Gas Calibration Message Router 
Trip Point Assembly or Message Router 
Discrete Output Point Message Router 
Analog Output Point Message Router 

I/O Assembly Instances 


The manufacturer of a Gauge Device must specify which Assembly instances are supported by 
the device. 


The S-Analog Sensor object definition specifies a behavior that modifies the Data Type of 
certain attributes based upon the first valid I/O connection established to an Assembly Object 
instance. In order to maintain consistency, this device type will only allow connections to either 
INT or REAL based Assembly instances. Once a valid connection is established, attempts to 
configure connections, or otherwise access data, to a different type of Assembly instance will 
return a RESOURCE UNAVAILABLE error. 


Combination Gauges 

Though the device supports multiple instances of the S-Analog Sensor class, only a single 
Pressure Value is produced in the Assemblies. The S-Analog Sensor class-level attribute 
Active Instance Number identifies the object instance that is currently active and providing its 
Pressure Value to the Active Pressure Value which is, in turn, produced by the input 
assemblies. Note that this behavior does not apply to the Trip Point and the Analog Output 
Point objects, which are directly linked to S-Analog Sensor instances. 
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Multiple Gauges 

Multiple pressure values are available from multiple S-Analog Sensor instances and are 
provided in each assembly instance that contains multiple Pressure Value members indicated 
by Pressure Value n, where n corresponds to the S-Analog Sensor instance ID. The maximum 
number for 7 is specified by the value of the S-Analog Sensor object class attribute Number of 
Gauges. For devices with fewer gauges than the number specified in a given input assembly, 
the missing Data Components of that assembly will be set to zero (0). Note that for the purpose 
of bandwidth optimization, I/O connections to such assemblies where less than the included 
number of instances are valid, the I/O connection produce length can be set accordingly. 


The following table identifies the I/O assembly instances. The manufacturer must specify 
which Assembly instances are supported by the device. 


Instance | Required | Type | Byte | Bit7 | Bit6 | Bit5 | Bit4 | Bit3 | Bit2 | Bit1 | Bit0O 


1 INT Pressure Value 


2 Y Input} 0 Exception Status 
(default) 
1-2 INT Pressure Value 
3 N Input} 0 Exception Status 


Trip |Trip |Trip |Trip |Trip |Trip |Trip |Trip 
Status | Status | Status | Status | Status | Status | Status | Status 
Inst. |Inst. |Inst. |Inst. |Inst. |Inst. |Inst. | Inst. 1 
8 7 6 5 4 3 2 

2-3 INT Pressure Value 


REAL Pressure Value 
N Input} 0 Exception Status 
1-4 REAL Pressure Value 
Exception Status 
Trip |Trip |Trip |Trip |Trip |Trip |Trip |Trip 
Status | Status | Status | Status | Status | Status | Status | Status 
Inst. |Inst. |Inst. |Inst. |Inst. |Inst. |Inst. |Inst. 1 
8 7 6 5 4 3 2 
2-5 REAL Pressure Value 
Exception Status 
Trip |Trip |Trip |Trip |Trip |Trip |Trip |Trip 
Status | Status | Status | Status | Status | Status | Status | Status 
Inst. |Inst. |Inst. |Inst. |Inst. |Inst. |Inst. |Inst. 1 
8 7 6 5 4 3 2 
Exception Status 
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Exception Status 

1-2 Active Instance 

3-4 INT Active Pressure Value 
11 N Input} 0 Exception Status 

| |Trip |Trip |Trip |Trip |Trip |Trip |Trip |Trip 

Status | Status | Status | Status | Status | Status | Status | Status 
Inst. |Inst. |Inst. |Inst. |Inst. |Inst. |Inst. | Inst. 1 
8 7 6 > 4 3 2 


2-3 Active Instance 
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Instance | Required | Type | Byte 
12 N Input | 0-1 
2-5 
/ 7 
14 N Input} 0 
1 
. 
| 
| 
| 
| 
20 N Input 
1 
2-5 
6-9 
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Bit7 | Bit6 | BitS | Bit4 | Bit3 | Bit2 | Bit1 | BitO 


INT Active Pressure Value 
Active Instance 
REAL Active Pressure Value 
Exception Status 
Active Instance 
REAL Active Pressure Value 
Exception Status 
Trip |Trip |Trip |Trip 
Status | Status | Status | Status 
Inst. |Inst. |Inst. | Inst. 
6 5 4 3 
Active Instance 
REAL Active Pressure Value 
INT Pressure Value 1| 
INT Pressure Value 2 
INT Pressure Value 3 
INT Pressure Value 4 
Exception Status 
NT Pressure Value 1 
NT Pressure Value 2 
NT Pressure Value 3 
NT Pressure Value 4 
Exception Status 


Trip | Trip 
Status | Status 
Inst. | Inst. 

8 7 


Trip | Trip 
Status | Status 
Inst. | Inst. 1 
2 


Sess 


Trip | Trip 
Status | Status 
Inst. | Inst. 

8 7 


Trip |Trip |Trip |Trip |Trip | Trip 
Status | Status | Status | Status | Status | Status 
Inst. |Inst. |Inst. |Inst. |Inst. | Inst. 1 
6 5 4 3 2 
INT Pressure Value | 
INT Pressure Value 2 
INT Pressure Value 3 
INT Pressure Value 4 
REAL Pressure Value 1 
REAL Pressure Value 2 
REAL Pressure Value 3 
REAL Pressure Value 4 


Exception Status 
REAL Pressure Value 1 
REAL Pressure Value 2 
REAL Pressure Value 3 
REAL Pressure Value 4 


Exception Status 
Trip |Trip |Trip |Trip |Trip |Trip |Trip |Trip 
Status | Status | Status | Status | Status | Status | Status | Status 
Inst. |Inst. |Inst. |Inst. |Inst. |Inst. |Inst. | Inst. 1 
8 7 6 5 4 3 2 
REAL Pressure Value 1 
REAL Pressure Value 2 
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Instance | Required | Type | Byte 
21 N 
22 N 
23 N 
24 N Input | 0-3 
4-7 
8-11 
12 - 
15 
16 - 
19 


Bit 7 


Trip 


Bit 6 


Trip 


Bit 


Trip 


5 | Bit4 | Bit3 | Bit2 | Bit1 | BitO 


REAL Pressure Value 3 


REAL Pressure Value 4 


NT Pressure Value 1 
NT Pressure Value 2 
NT Pressure Value 3 
NT Pressure Value 4 
NT Pressure Value 5 
NT Pressure Value 6 


Ss Ss Se Se SS 


INT Pressure Value 7 


INT Pressure Value 8 


Exception Status 

NT Pressure Value 1 
NT Pressure Value 2 
NT Pressure Value 3 
NT Pressure Value 4 
NT Pressure Value 5 
NT Pressure Value 6 


SSeS Se eS 


INT Pressure Value 7 


INT Pressure Value 8 


Exception Status 
Trip | Trip | Trip 


Trip | Trip 


Status | Status | Status | Status | Status | Status | Status | Status 


Inst. 
8 


Inst. 
7 


Inst. 
6 


Inst. | Inst. | Inst. 
5 4 3 
NT Pressure Value 1 
NT Pressure Value 2 
NT Pressure Value 3 
NT Pressure Value 4 
NT Pressure Value 5 


Sess Ss 


INT Pressure Value 6 


INT Pressure Value 7 


INT Pressure Value 8 


REAL Pressure Value 1 
REAL Pressure Value 2 
REAL Pressure Value 3 
REAL Pressure Value 4 


REAL Pressure Value 5 
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Instance | Required | Type | Byte | Bit7 | Bit6 | Bit5 | Bit4 | Bit3 | Bit2 | Bit1 | Bit0O 


20 - REAL Pressure Value 6 
23 

24 - REAL Pressure Value 7 
27 

28 - REAL Pressure Value 8 
31 

25 N Input Exception Status 

REAL Pressure Value 1 

REAL Pressure Value 2 

REAL Pressure Value 3 

REAL Pressure Value 4 

REAL Pressure Value 5 

REAL Pressure Value 6 

REAL Pressure Value 7 

REAL Pressure Value 8 


26 N Input Exception Status 
Trip |Trip |Trip |Trip |Trip |Trip |Trip |Trip 
Status | Status | Status | Status | Status | Status | Status | Status 
Inst. |Inst. |Inst. |Inst. |Inst. |Inst. |Inst. | Inst. 1 
8 7 6 5 4 3 2 

REAL Pressure Value 1 

REAL Pressure Value 2 


REAL Pressure Value 3 
REAL Pressure Value 4 
REAL Pressure Value 5 
REAL Pressure Value 6 
REAL Pressure Value 7 


REAL Pressure Value 8 


All of the elemental components listed above follow standard CIP Data Encoding as specified 
in Appendix C. 


Mapping I/O Assembly Data Attribute Components 


The Data Type of the Pressure Value attribute below (and the Data Type of other objects used 
in this profile) is based upon the first valid I/O connection established to an Assembly Object 
instance. See text of 6-32.4.1. 


The following table indicates the I/O assembly Data attribute mapping for this Gauge device. 
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Data Instance 
Component Number 
Name 


Active Instance 
Number 


Active Pressure 
Value * 


* For Combination Gauges only 


Object Limitations and Specific Definitions 


6-32.5.1. S-Device Supervisor Object Instance 
6-32.5.1.1. Exception Attributes Definition 


Release 1.0 


The following table specifies the data attribute bit mapping for the Device Exception Detail 
bytes for this device. For more descriptive information, see the definition of the S-Device 
Supervisor Object Class. 


All status and Sensor” bits originate from the S-Analog Sensor object. The meaning of Sensor 
Alarm and Sensor Warning is defined by the Gauge Subclass used. See the object specification 
for the detailed bit mapping. Noted with each entry is the Instance from which the status 
byte/bit is mapped. 


Combination and multiple gauges will have a set of Device Exception details for each gauge. 
The S-Analog Sensor class attribute Number of Gauges is used to determine gauge count. 


Any Exception Bit not supported shall be set to zero (0). Note that this profile allows for only 
one byte of manufacturer exception detail. 
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Exception Detail Warning (Attribute 14): 


x x x x 


Data 
Component 


Device Exception 
Detail (Warning) 
Size 


Device | 
Exception Detail 
(Warning) Byte 0 


S-Analog Sensor object Instance 1 — Status Extension 


Device | 
Exception Detail 
(Warning) Byte 1 


S-Analog Sensor object Instance 1 — Sensor Warning — Byte 0 


Device 1 
Exception Detail 
(Warning) Byte 2 


S-Analog Sensor object Instance 1 — Sensor Warning — Byte 1 


Combination and Multi-Gauge Devices Only: 


Device N S-Analog Sensor object Instance N — Status Extension 
Exception Detail 
(Warning) Byte 0 

Device N S-Analog Sensor object Instance N — Sensor Warning — Byte 0 


Exception Detail 
(Warning) Byte 1 


Device N 
Exception Detail 
(Warning) Byte 2 


S-Analog Sensor object Instance N— Sensor Warning — Byte 1 


{End Combination and Multi-Gauge Devices Only] 


Manufacturer 
Exception Detail 
(Warning) Size 


Manufacturer 
Exception Detail 


(Warning) 


8 bits defined by Manufacturer 
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Exception Detail Alarms (Attribute 13): 


x x x 


Data 
Component 


Device Exception 
Detail (Alarm) 
Size 


Device 1 
Exception Detail 
(Alarm) Byte 0 


S-Analog Sensor object Instance 1 — Sensor Alarm — Byte 0 


Device 1 
Exception Detail 
(Alarm) Byte 1 


S-Analog Sensor object Instance 1 — Sensor Alarm — Byte 1 


Combination and Multi-Gauge Devices Only: 


Device N S-Analog Sensor object Instance N — Sensor Alarm — Byte 0 
Exception Detail 
(Alarm) Byte 0 
Device N S-Analog Sensor object Instance N — Sensor Alarm — Byte 1 


Exception Detail 
(Alarm) Byte 1 


{End Combination and Multi-Gauge Devices Only] 


Manufacturer 
Exception Detail 
(Alarm) Size 


Manufacturer 
Exception Detail 
(Alarm) 


8 bits defined by Manufacturer 


6-32.5.1.2. |Manufacturer’s Device Type Attribute Definition 


The following limitations apply: 


Attribute Need in Access | Name | Data Type Description of Attribute 
ID implementation | Rule 


3 Required Get Device |SHORT Supported values: 

Type STRING — | »vG” for single-instance vacuum 
gauge 

”*CG” for combination gauge 

*MG” for multiple gauge 

(ref S-Analog Sensor instance 

attribute Subclass Number to 

determine specific gauge type) 
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6-32.5.1.3. Behavior 


The behavior of all Pressure/Vacuum Gauge objects are defined by the S-Device Supervisor 
Object in Chapter 5. 


Ion Gauges only — the Emission OFF state will result in the following behavior: 

a) S-Analog Sensor Value attribute will revert to the Safe State / Safe Value, if supported. This 
mimics the non-executing state of the device. 

b) The Trip Point (if supported) Status attribute will be set to the unasserted state (Override, if 
supported, = 1). 


6-32.5.2. S-Analog Sensor Object Instance 
6-32.5.2.1. Limitations 
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Object Instance Number Assignment 


The following instance numbering limitations apply: 


Instance Description 


Reserved for Pressure Gauges 
21... 60 


Reserved for Interlock-Relay Setting Monitors 


Data Type, Data Units and Produce Trigger Delta Type 
The following attribute limitations apply: 


Attribute Additions / Limitation Requirements 


Data Type Supported Values = {INT, REAL} Supported Value 
Access Rule = Get only, after an assembly instance = {INT} 


connection is established 


Data Units Supported Values limited to those found in Group 4 — Supported Value 
Pressure” of Data Units Appendix K, and Counts. = {Counts} 
Produce Percent Percent 


Trigger Delta 
Type 


All devices are required to support INT Counts. The meaning of Counts is vendor-specific. 
Which combinations of Data Units and Data Type are supported are vendor-specific. INT 
Counts and/or REAL Pressure Units are the most likely options. Other combinations (ex. 
REAL Counts) may not be supported. 


Multiple gauges and combination gauges will require multiple instances of the S-Analog 
Sensor Object, all of which will support the same Data Type and Data Units. 


Alarm and Warning Hysteresis (attributes 19 and 23) 
For gauges with a logarithmic vacuum reading (hot cathode ion gauge, cold cathode ion gauge, 
and heat transfer gauges) the Alarm and Warning Hysteresis attributes determine the amount 


(in the unit "percent of the associated alarm/warning value" ) by which the Value must recover 
to clear an Alarm Condition. 
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For gauges with a linear vacuum reading (Diaphragm Gauge) the Alarm and Warning 
Hysteresis attributes determine the amount (absolute) by which the Value must recover to clear 
an Alarm Condition. 


6-32.5.2.2. Object Extensions 


This profile uses the extensions for the following instance-level subclasses: 


Gauge Type Subclass Number 
Heat Transfer Vacuum Gauge | 02 
Diaphragm Gauge 03 
Cold Cathode Ion Gauge 04 
Hot Cathode Ion Gauge 05 


6-32.5.3. Trip Point Object Instance 
6-32.5.3.1. Limitations 


Release 1.0 


Hysteresis (attribute 10) 

For gauges with a logarithmic vacuum reading (hot cathode ion gauge, cold cathode ion gauge, 
and heat transfer gauges) the Hysteresis attribute determines the amount (in the unit "percent of 
the associated low/high trip point" ) by which the Value must recover to clear a trip point 
condition. 

For gauges with a linear vacuum reading (Diaphragm Gauge) the Hysteresis attribute 
determines the amount (absolute) by which the Value must recover to clear a trip point 
condition. 

Source (attribute 14) 

Abbreviated EPATH — the Source attribute in this device type is abbreviated as follows: 
Logical Segment, Instance Only, 8-bit Logical Address (see Appendix C). 

The following defaults apply: 


Class ID = 31), [S-Analog Sensor]. 
Attribute ID = 06 [Value]. 


Therefore, the source attribute uses the following encoding: 


2Anex Xx 


Where x is the Instance ID of the S-Analog Sensor object whose Value attribute is the source. 
Destination (attribute 12) 
Abbreviated EPATH — the Destination attribute in this device type is abbreviated as follows: 


Logical Segment, Instance Only, 8-bit Logical Address (see Appendix C). 
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The following defaults apply: 


Class ID = 09, [Discrete Output Point]. 
Attribute ID = 03 [Value]. 


Therefore, the source attribute uses the following encoding: 


2A4nex 


xX 
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Where x is the Instance ID of the Discrete Output Point object whose Value attribute is the 


Destination. 


Defining Device Configuration 


Public access to the S-Device Supervisor, S-Gas Calibration, and S-Analog Sensor Objects by 
the Message Router must be supported for configuration of this device type. There is no 


Parameter Object defined for access to the device type’s configuration parameters. 
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6-33. CONTROLNET PROGAMMABLE LOGIC CONTROLLER 


Device Type: 0Ehex 


The ControlNet Programmable Logic Controller Device type defines a device that acts as a 
scheduled connection originator. No control functions are included in this profile. 


6-33.1. Object Model 
The table below indicates: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Object Class # of Instances 
Message Router 1 
ControlNet 1 
Connection Manager 1 
Scheduling 1 


The ControlNet Programmable Logic Controller Device profile cannot specify the definition of 
the Assembly Object or the type of application objects necessary for device operation. This 
portion of the device profile must be supplied by the product developer as described earlier in 
this chapter, Contents of a Device Profile. 


6-33.2. Defining Object Interfaces 


The objects in the ControlNet Programmable Logic Controller Device have the interfaces listed 
in the following table: 


Object Interface 
Identity Message Router 
Message Router Explicit Messaging Connection Instance 
Network Specific Link Object Message Router 
Connection Manager Message Router 


Scheduling Message Router 
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6-34. CONTROLNET PHYSICAL LAYER COMPONENT 
Device Type: 32hex 


The ControlNet Physical Layer Component shall not be addressable from the link. This device 
type shall include repeaters and various media for the ControlNet physical layer. 


6-156 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification 


Chapter 7: Electronic Data Sheets 


Chapter 7: Electronic Data Sheets Volume 1: CIP Common Specification 


This page is intentionally left blank 


7-2 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 7: Electronic Data Sheets 


7-1. INTRODUCTION 
This chapter describes: 


e standardized methods for device configuration 
e the structure of an Electronic Data Sheet (EDS) 


The information provides reference material for: 


e product developers 
e configuration tool designers 


7-1.1. Terms and Definitions Used in this Chapter 


Term Meaning 
decoded format The decoded attribute data values in CIP message format 
EDS The abbreviation for Electronic Data Sheet, a file on disk that contains 
configuration data for specific device types 
encoded format The encoded attribute data values in the Electronic Data Sheet Format 
CIP path The address of an object attribute in CIP Class-Instance-Attribute format 
parameter object: An object that has two types, as specified below 
full An object within a device that contains the configuration data value, prompt strings, 


data conversion factors, and other information associated with a device 


stub A shorthand form of a parameter object that stores only the configuration data value 
and provides only a standard access point for the parameter 
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7-2. 


7-2.1. 


CONFIGURATION OPTIONS 


The CIP standard allows for remote device configuration across the network and for embedding 
configuration parameters in devices. Using these features, you can select and modify device 
configuration settings for use in a particular application. The CIP interface allows access to a 
device’s configuration settings. 


CIP Network 


Configuration 
Commands 


of of of ofo] of of 0 
wall rad | 0} of of of of of o} o 
of of of ofof of of 0 
of of of of of of of 0 


Device Device 


Device 


Information 
Device 


Configuration 
Tool 


Devices containing configuration settings accessible only through the CIP communications 
interface require a configuration tool to change these settings. Devices configured only through 
the use of external switches, jumper blocks, thumbwheels, or other proprietary interfaces do not 
require a configuration client (tool) to modify the device’s configuration settings. However, the 
device designer must provide a means for a tool to access and determine the state of hardware 
configuration switches. 


Configuration Data Sources and Methods 


This chapter describes possible methods for storing and accessing a device’s configuration 
data. 


e A printed data sheet 

e An Electronic Data Sheet (EDS) 

e Parameter Objects and Parameter Object Stubs 

e Acombination of an EDS and Parameter Object Stubs 

e A Configuration Assembly and any of the above methods 


7-2.1.1. | Configuration Support Using Printed Data Sheets 


7-4 


When using configuration information collected on a printed data sheet, configuration tools can 
only provide prompts for service, class, instance, and attribute data and relay this data to a 
device. A configuration tool of this type does not determine the context, content, or format of 
the data. The figure below shows the relationship between configuration information and the 
tool. 
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Configuration Support Using an Electronic Data Sheet 


You can provide configuration support for your device by using a specially formatted ASCII 
file, referred to as the Electronic Data Sheet (EDS). An EDS provides information about the 
device configuration data’s: 


e §=context 
e §=content 
e format 


The information in an EDS allows configuration tools to provide informative screens that guide 
a user through the steps necessary to configure a device. Section 4—3 describes electronic data 
sheets. 


An EDS provides all of the information necessary to access and alter the configurable 
parameters of a device. This information matches the information provided by instances of the 
Parameter Object Class. The CIP Object Library describes the Parameter Object Class in 
detail. 


Manufacturers who choose not to supply an EDS on computer-readable media can provide a 
printed listing of their EDS so that the end user may create the computer-readable EDS using a 
text editor. 


The following figure shows device configuration by a configuration tool that supports an EDS. 


The application objects in the device represent the destination addresses for configuration data. 
These addresses are encoded in the EDS. 
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Configuration Support Using Parameter Objects and Parameter Object Stubs 


The device’s public Parameter Object, which is an optional data structure in a device, provides 
a third method for accessing the configuration data of a device. When a device uses parameter 
objects, it requires one instance of the Parameter Object class for each supported configuration 
parameter. Each instance is linked to a configurable parameter that can be an attribute of one of 
the device’s other objects. Changing the Parameter Value attribute of a Parameter Object 
causes a corresponding change in the attribute value, as indicated by the Link Path attribute. 


A Full Parameter Object contains all of the information necessary for device configuration. 
The CIP Object Library, contains a complete definition of the Parameter Object. A partially 
defined Parameter Object, called a Parameter Object Stub, contains the portion of 
configuration information needed to perform configuration that excludes user prompts, limit 
testing, and descriptive text that guides a user through the configuration. 


Using Full Parameter Objects 
Parameter Objects embed all of the needed configuration information within the device. 


Parameter Objects provide: 


e aknown public interface to a device’s configuration data values 
e descriptive text 
e = data limits, default, minimum, and maximum values 


Important: When a device contains full Parameter Objects, a configuration tool may derive all 
of the needed configuration information directly from the device. 


The following figure shows the configuration of a device by a configuration tool that supports 
full Parameter Objects. 
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Using Parameter Object Stubs 


Parameter Object stubs provide an established address to a device’s configuration data values 
without requiring specification of descriptive text, data limits, and other parameter properties. 
When a device contains Parameter Object stubs, a configuration tool may obtain additional 
configuration information from an EDS or provide only a minimal interface to a parameter for 
modification. 


7-2.1.4. | Configuration Using an EDS and Parameter Object Stubs 


A configuration tool may obtain information from partial Parameter Objects or Parameter 
Object stubs embedded in a device that provides a companion EDS. The EDS supplies 
additional parameter information needed by a configuration tool. The Parameter Object stubs 
can provide a known public interface to a device’s parameter data values, while the EDS 
supplies descriptive text, data limits, and other parameter properties such as the: 


Data type and size for data validation 
Default data selections 

Descriptive user prompts 

Descriptive help text 

Descriptive parameter names 


The figure below shows the configuration of a device by a configuration tool that supports 
Parameter Object stubs with electronic data sheets. 
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7-2.1.5. Configuration Using a Configuration Assembly 


An instance of the Configuration Assembly allows bulk upload and download of configuration 
data. If you use this method for device configuration, you must document: 


e The format of the configuration data blocks 
e The address mapping for each configurable attribute 


When specifying the data attribute of the Configuration Assembly, you must: 


e List the data components in the order given by the attribute block 

e List data components larger than one byte starting with the low order byte 

e List data components smaller than one byte justified to the right within a byte, starting 
with bit 0 


Show the format of the data blocks in a table like the following: 


Byte 


n Input Range 


In addition to specifying the device’s Configuration Assembly’s data format, you must map the 
individual configuration data components to their associated objects. Do this by specifying the 
Class, Instance, and Attribute IDs for each data component. This is essentially the same as 
specifying the Member _List attribute of the Assembly Object. 
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The table below shows an example mapping of Configuration Assembly data attribute 
components: 


Data Instance Attribute Data 
Component Number Type 
Name 


Output Range | Analog Output Output Range UINT 


ie) 
ie) 


ie) 
Input Range Analog Input Input Range BYTE 
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7-3. ELECTRONIC DATA SHEET DEFINITION 


This section contains the formal specification of the electronic data sheet (EDS). The EDS 
allows a configuration tool to automate the device configuration process. The EDS 
specification provides an open standard for device configuration and compatibility among all 
CIP products. 


7-3.1. The Electronic Data Sheet 


An EDS may contain vendor-specific information in addition to the required device parameter 
information defined by this specification. The figure below shows a general block diagram of a 
sample EDS. 
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The Product Data Sheet Model 


Electronic data sheets follow a product data sheet metaphor, modified to accommodate CIP 
requirements. Typically, a product data sheet provides a user with information needed to 
determine the product’s features and the range of user-assigned values that may be selected for 
these features. 


Product Name: Smart Widget I1 Series Z99 Dual Mode <= Name of the product 
Vendor: Always Profitable Widget Works, Inc. <= Who made it 

Model: Z99 DM <= Catalog number 
Revision: 2.1 <= Revision level 

Serial Number: 00123456789A <= Unique serial number 


2. Scale Factor 
3. Output Mode 
4. Output Frequency 


5. Status Register 


The data sheet conveys information from the product manufacturer to the product user. The 
product user interprets the manufacturer’s data sheet, decides which settings must be set to 

non-default values, and performs the necessary actions to get the information from the data 
sheet into the device. 


A configuration tool that uses an EDS and parameter object stubs follows this same sequence, 
using an electronic form of the data sheet. 


To perform the actual configuration, a configuration tool uses CIP messaging to perform the 
changes in the device. Currently, the textual information in an EDS must be 
ASClI-representable characters. Future revisions of this specification will support non-ASCII 
character representations such as UNICODE. 


The EDS serves two main purposes by providing information needed to: 


e Describe each device parameter, including its legal and default values 
e Provide the user with a selection of choices for each configurable parameter in a device 


Open DeviceNet Vendor Assoc. & ControlNet International 7-11 


Chapter 7: Electronic Data Sheets Volume 1: CIP Common Specification 


The figure below compares the interpretation of a printed data sheet by a human with the 
interpretation of an EDS by a configuration tool. At the minimum, a CIP configuration tool 


must: 
e Load the EDS into the configuration tool’s memory 
e Interpret the EDS contents to determine the characteristics of each parameter 
e Present to the user a list of choices or data entry fields for each device parameter 
e Load the user’s parameter choices to the correct parameter addresses in the device 
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Apply 
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ee. 
Apply 


Changes to 
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UF 
Product developers may add optional EDS-related functions to a configuration tool. The 


specified EDS requirements provide a consistent and compatible approach for performing 


configuration in the CIP environment. This specification enforces only the requirements critical 
to achieving: 


User Decides Which 
Settings to Change 


e Consistency among vendors for the benefit of device makers 
e Compatibility among vendors for the benefit of tool makers 
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All EDS developers must implement EDSs compliant with these requirements. Product 
developers determine all other implementation details. Every EDS interpreter designed for CIP 
products must be capable of: 


e Reading and interpreting any standard EDS 
e Presenting information and choices to device users 
e Building the messages necessary to configure the associated CIP product 


The specification, in CIP Communication Model and Protocol, imposes strict requirements and 
protocols for transmitting messages over the CIP network. The figure below shows the 
compliancy required for each configuration process. The remainder of this chapter describes 
the requirements which must be satisfied for all configuration tools that use an EDS. These 
requirements describe: 


e EDS encoding 
e EDS command language 
e EDS syntax 


Configuration Compliance 
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Read the EDS DeviceNet Electronic Data Sheet 
Requirements Specification 
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[ Strict Compliancy Required 


Release 1.0 Open DeviceNet Vendor Assoc. & ControlNet International 7-13 


Chapter 7: Electronic Data Sheets Volume 1: CIP Common Specification 


7-3.3. | Using an EDS with Configuration Tools 


CIP configuration tools: 


e Extract user prompt information from a standard EDS 
e Present this information to the user in a human-readable form 


The tool developer determines the: 


e user interface format 
e operator interaction 


7-3.3.1. | EDS Interpreter Functions 


The interpreter must: 


e Collect parameter selections required by an EDS 
e Build the CIP messages necessary to configure a device 
e Contain the object addresses for each device parameter requiring configuration 


7-3.3.2. EDS File Organization 


This section contains the file encoding requirements for EDSs. The figure below shows a block 
diagram of the structure of an electronic data sheet. The EDS encoding requirements define the 
standard file encoding format to use for CIP products without regard to the configuration tool 
host platform or file system. 
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Electronic Data Sheet 
[File] 


File Description Section 


[Device] 


Device Description Section 


[Assembly] 


Assembly Description Section (Optional) 


[ParamClass] 


Parameter Class Section (Optional) 


[Params] 


Parameter Section 
Standard Device Parameters (Optional) 


Vendor-Specific Parameters (Optional) 


[Groups] 
Parameter Groups Section (Optional) 


The term “file” as used in this chapter refers to any recognized file format associated with a 
configuration tool’s file system without regard to the file storage media. An EDS contains an 
ASCII representation of a device’s Parameter Objects and some additional information required 
to support object addressing. 


EDS Content 


A single file must contain the entire EDS. The following table summarizes the structure of the 
sections, legal section delimiters, and the order of sections in an EDS. 


Section Name Required/Optional 
File Description Required 
Device Description Required 
Parameter Class Optional 
Parameters Optional 
Parameter Groups Optional 
Assembly Optional 
Device Classification Optional 
Connection Characteristics Optional 
Port [Port] Optional 
Modular Optional 


*Placement of optional groups only needs to follow the required groups 
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Observe these rules when defining an EDS: 


e Sections - The EDS file must be partitioned into required and optional sections. 


e Section delimiters - Each section in the EDS must be properly delimited by a section 
keyword in square brackets (the Legal Delimiter). 


e Section order - Each required section must be placed in the required order. Optional 
sections can be omitted entirely or included with empty data place holders. 


e Entry - Each section in the EDS contains one or more entries beginning with an entry 
keyword followed by an equal sign. The entry keyword meaning depends on the context 
of the section. A semicolon indicates the end of the entry, and entries may span multiple 
lines. 


e Entry fields - Each entry contains one or more fields. A comma delimiter separates 
each field. The meaning of the field(s) depends on the context of the section. 


e WVendor-Specific Keywords - Section and Entry Keywords may be vendor-specific. 
These keywords shall begin with the Vendor ID of the company making the addition 
followed by an underscore (VendorID_VendorSpecifickeyword). The VendorID shall 
be displayed in decimal and shall not contain leading zeroes. Each vendor is 
responsible for maintaining and documenting their vendor-specific keywords. 


The following examples highlight the structure of the electronic data sheet. (Note: The “$” 
character denotes a comment.) 


[section name] 
$ Comment - extends to end of line 
Entryl=Fieldl, Field2, Field3; $ Entire entry on one line 
Entry2=Fieldl, Field2, Field3, Field4; $ Entire entry on one line 
Entry3= $ Multiple line entry 

Fieldl, $ Fieldl 

Field2, Field2 

Field3; Field3 


Fieldl, Field2, 
Field3, 
Field4; $ Field4 

65535_Entry= $ Vendor Specific entry for Vendor ID 65535 
Field1l, Field2; $ with two fields 


Fields 1 and 2 on one line 
Field3 


$ 
$ 
$ Combination 
$ 
$ 


Note from the examples that an entry can extend over multiple lines as long as commas 
properly delimit the fields. The configuration tool ignores any whitespace characters, including 
comments, tabs, and spaces. Comments start at the comment delimiter ($) and extend to the end 
of the line. All entries must terminate with a semicolon. 


File Naming Requirements 


Currently no file naming conventions exist for disk-based EDS files, except for files in a 
DOS/Windows environment. The file should have the suffix “.EDS” appended to the file name. 
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7-3.4. EDS Data Encoding Requirements 


This section describes the data encoding requirements for the EDS file. 


7-3.4.1. ASCII Character Convention 


All data in the EDS must be encoded using 8-bit ASCII characters, where all references to 
“ASCII characters” mean an 8-bit ASCII character format. Characters that cannot be displayed 
on an ANSI terminal cannot be used in identifier names or in data representations. 


7-3.4.2.. ASCII Character String Convention - (STRING) 


All references to STRING in this chapter mean ASCII character strings of fixed length without 
null terminators. Double quotes enclose all strings. 


Handling Insufficient Characters in a String Field 


An EDS interpreter uses right-justification of characters in a field and fills any unspecified 
characters with leading blanks (ASCII 0x20) for the remaining length of the string. For 
example, if a parameter has a maximum string length of 8 and receives the string 


“123—B", 

the interpreter decodes the string as 
"~w~123AB”, 

where the tilde characters (~) represent spaces. 

Handling Excess Characters in a String Field 


If a given string field contains too many characters, the EDS interpreter truncates characters 
from left to right. For example, if a parameter has a maximum string length of 8 and receives 
the string 


”"I23ABCDEFG”, 


the EDS interpreter truncates the string to 


”"I23ABCDE” . 


7-3.4.3. String Concatenation 


Multiple strings with no intervening commas are concatenated. For example, the line 
“BBC” “we 123” "XYZ" 
is interpreted as 


"BBC123XYZ” 
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The strings may also be on separate lines. For example, the following lines 


“BBC” Sthis is a comment 
uw 12 3 aw 
"XYZ Lf 


are also interpreted as 


"BBC123XYZ” 


7-3.4.4. String Escape Sequences 


The interpreter recognizes the following escape characters in a string and translate them: 


\\ translates to a \ 

\n translates to a newline 
\t translates to a tab 

\’ translates to a” 


7-3.4.5. ASCII Unsigned Integer Convention - (USINT, UINT, UDINT, ULINT) 


The unsigned integer data types represent positive integer values. Unsigned integer data may be 
entered in decimal or hexadecimal notation with no whitespace or commas between characters. 
If hexadecimal notation represents the unsigned integer characters, the two character sequence 
Ox, with no white space, shall precede the unsigned integer characters. 


The range of legal USINT data is: 


Decimal Notation: 0 to 255 
Hexadecimal Notation: 0x0 to OxFF 
The range of legal UINT data is: 
Decimal Notation: 0 to 65535 
Hexadecimal Notation: 0x0 to OxFFFF 
The range of legal UDINT data is: 
Decimal Notation: 0 to 4294967295 
Hexadecimal Notation: 0x0 to OxFFFFFFFF 
The range of legal ULINT data is: 
Decimal Notation: 0 to 18446744073709551615 
Hexadecimal Notation: 0x0 to OxFFFFFFFFFFFFFFFF 


7-3.4.6. | ASCII Signed Integer Convention - (SINT, INT, DINT, LINT) 


The SINT, INT, DINT and LINT data types represent signed integer data values. Signed 
integer data may be entered in decimal or hexadecimal notation with no whitespace or commas 
between characters. If hexadecimal notation represents the signed integer characters, the two 
character sequence 0x, with no white space, shall precede the integer value characters. 


The range of legal SINT data is: 
Decimal Notation: -128 to 127 
Hexadecimal Notation: 0x80 to Ox7F 
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The range of legal INT data is: 
Decimal Notation: 
Hexadecimal Notation: 


The range of legal DINT data is: 
Decimal Notation: 
Hexadecimal Notation: 


The range of legal LINT data is: 
Decimal Notation: 


Hexadecimal Notation: 
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32767 
Ox7FFF 


-32768 to 
0x8000 to 


-2147483648 to 2147483647 
0x80000000 to Ox7FFFFFFF 


-9223372036854775808 to 223372036854775807 
0x8000000000000000 to Ox7FFFFFFFFFFFFFFF 


ASCII Word Convention - (BYTE, WORD, DWORD, LWORD) 


The BYTE, WORD, DWORD and LWORD data types represent bit-addressable values. These 
values are considered discrete bit position values and are not intended to represent either signed 
or unsigned integer values. However, these values, for convenience, may be entered in 
decimal, hexadecimal or binary notation with no whitespace or commas between characters. If 
hexadecimal notation represents value characters, the two character sequence 0x, with no white 


space, shall precede the value characters. 


The range of legal BYTE data is: 
Decimal Notation: 
Hexadecimal Notation: 
Binary Notation: 


The range of legal WORD data is: 
Decimal Notation: 
Hexadecimal Notation: 
Binary Notation: 


The range of legal DWORD data is: 


Decimal Notation: 
Hexadecimal Notation: 
Binary Notation: 


The range of legal LWORD data is: 


Decimal Notation: 
Hexadecimal Notation: 
Binary Notation: 


CIP Path 


0 to 255 
0x0 to OxFF 
0b00000000 to 0b11111111 


0 to 65535 
0x0 to OxFFFF 
0b0000000000000000 to 0b1111111111111111 


0 to 4294967295 

0x0 to OxFFFFFFFF 
0b00000000000000000000000000000000 to 
ObLLILILLIDIT111111111111111111111 


0 to 18446744073709551615 

0x0 to OxFFFFFFFFFFFFFFFF 

0b00000000000000000000000000000000- 
00000000000000000000000000000000 to 
ObLL1111211111111111111111111111111- 
L1D12111111111111111111111111111 


The CIP path string, having the type STRING, follows the format defined in this specification. 
The CIP path consists of groups of two adjacent hexadecimal characters separated by spaces. 
Double quotes enclose the entire string. Some example path strings are: 
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7-3.4.10. 


7-3.4.11. 


NOTE: 


7-20 


Path Ex.1: “20 04 24 01” 
Path Ex.2: “20 05 24 02 30 04” 


EDS White Space 


The EDS interpreter treats certain characters as white space characters. These characters, read 
by the interpreter but not encoded as human-readable characters, designate the presence of 
blank space in a file. White space characters include: 


e New line 

e Carriage Return 

e Line feed 

e Tabs, vertical and horizontal 
e End of File marker 


EDS Comments 


Comments must be delimited with the dollar sign character ($) and the new line character. The 
EDS interpreter treats all characters between the comment delimiters as white space. Some 
example comments are: 


$ This is a valid comment line <NL> 

1, 2, 3; $ This is a valid comment 

<NL> 

$ Comments cannot span <NL> 

more than one line <NL> <= This is an error - no § 
EDS Date 


The EDS_DATE data type shall be of the format; mm-dd-yyyy, where mm is the month, dd is 
the day of the month and yyyy is the year. Valid values for the month, day and year portions of 
the mm-dd-yyyy shall be 


* mm 01 through 12 
e dd 01 through 31 (depending upon the month and year) 
e  yyyy 1996 through 9999, 


Two character years representations may be used in which case the EDS_DATE data type shall 
be of the format; mm-dd-yy, where mm is the month, dd is the day of the month and yy is the 
year. In this case, the two digits for the year have an implied leading 19, such that yy=96 shall 
represent the year 1996. Valid values for the month, day and year portions of the mm-dd-yy 
parameters shall be: 


* mm 01 through 12 
e dd 01 through 31 (depending upon the month and year) 
e yy 96 through 99 (Note that a leading 19 is implied) 


Two character year representations are not recommended. 
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EDS Time Of Day 


The EDS_TIME OF DAY data type shall be of the format; hh:mm:ss, where hh is hours, mm 
iS minutes and ss is seconds. Valid values for the hours, minutes and seconds shall be: 


e hh 00 through 23 
e mm 00 through 59 
e ss 00 through 59 


ASCII Floating Point Convention (REAL, LREAL) 


The REAL and LREAL data types represent binary floating point values. The internal 
representation of these data formats are described by the IEEE Standard 754. This standard 
describes both numeric values and bit sequences which are interpreted as “Not a Number” 
(NaN) symbolic values and positive and negative infinity. The floating point values can be 
entered as either integer values, values based upon decimal floating point representation, or 
values entered in “scientific” notation using a base value and an offset in exponential form. 
Integer values are the same as those shown for the INT data type. These value can not be use 
to represent fractional values. Decimal floating point values are those which have both a whole 
integer and fractional component. The whole value and fractional components are separated by 
a decimal point “.” or period character. The exponential (scientific) notation form of the value 
is the same as the fractional value representation with the addition of an exponential 
component. This exponent is always a signed integer power to ten applied to the base value. 


The range of legal REAL data (single IEEE, 32 bit format) is based upon the formula: 
value = (-1)*«(2)°7’*(m) 


Where: 


e “s” is the value of the sign bit 


e “eis the eight bit exponent. This exponent allows an approximate exponent range 
between 0 and 8.5e°”. 

e “m’ is the normalized 24 bit mantissa (23 internal to the storage plus one hidden bit). 
This allows a range of mantissa values to range between 0 and 8388607. 


Since the mantissa of the floating point representation only allows a value digit value to be 
precisely represented by the internal format, an large number of digits within the decimal (or 
mantissa) portion of a floating value is more for presentation convenience than precision. An 
arbitrary limit of 16 digits has been set for the CIP standard. 


Integer (Fixed) Notation: -8388607 to 8388607 
Decimal (Floating Point) Notation: 0.0 to +9999999999999999 
Scientific Notation: 0.0 to tnn.nnnnnnnnnE+xxxx 


Where the total number of digits in the mantissa (including the decimal point character and sign 
character) shall not exceed 13 characters and the number of characters in the exponent shall not 
exceed 6 characters (including the “E” character and sign character) 
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Where: 


e “s” is the value of the sign bit 

e “eis the eleven bit exponent. This exponent allows an approximate exponent range 
between 0 and 8.5e°”. 

e “m’ is the normalized 53 bit mantissa (52 internal to the storage plus one hidden bit). 
This allows a range of mantissa values to range between 0 and 4503599627370495. 


Since the mantissa of the floating point representation only allows a value digit value to be 
precisely represented by the internal format, an large number of digits within the decimal (or 
mantissa) portion of a floating value is more for presentation convenience than precision. An 
arbitrary limit of 16 digits has been set for the CIP standard. 


The range of legal LREAL data (double IEEE, 64 bit format) is based upon the formula: 


value = (-1)°«(2)*"°*«(m) 


Integer (Fixed) Notation: -4503599627370495 to 4503599627370495 
Decimal (Floating Point) Notation: 0.0 to +9999999999999999 
Scientific Notation: 0.0 to nnnn.nnnnnnnnnnE+xxxx 


Where the total number of digits in the mantissa (including the decimal point character and sign 
character) shall not exceed 18 characters and the number of characters in the exponent shall not 
exceed 6 characters (including the “E” character and sign character) 


In addition to the above value entries, the floating point representation allows for two styles of 
“Not a Number” or NaN symbolic entries and two forms of infinity. There are two types of 
NaN; a Signaling NaN and a Quiet NaN. Also, the format allows for the representation of the 
values positive and negative infinity. For these cases, the following special words are reserved 
and shall be used to represent the entry of the associated floating point symbol: 


e Quiet Not a Number: QUIET-NAN 

e Signaling Not a Number: SIGNAL-NAN 

e Positive Infinity: INFINITY (or +INFINITY) 
e Negative Infinity: -INFINITY 


7-3.4.15. EDS URL Uniform Resource Locator 


All references to EDS_URL within this specification are for the formalized information 
necessary to locate and access resources via an internet capable mechanism. The form of the 
EDS_URL is that defined by the internet's Network Working Group RFC1738 "Uniform 
Resource Locator (URL)". For specifications made within an EDS file, the EDS_URL is 
limited to any of the forms: 


e http 
e ftp 
efile 
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7-3.5.1. 
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Chapter 7: Electronic Data Sheets 


Basic EDS File Requirements 


This section describes each section of an EDS and specifies the usage requirements. 


For EDS requirements for: Go to section: 
File description section 7-3.5.1 
Device description section 7-3.5.2 
Device Classification 7-3.5.3 
Parameter class section 7-3.5.4 
Parameters section 7-3.5.5 
Parameter groups section 7-3.5.6 
Assembly section 7-3.5.7 


File Description Section 


The file description section contains administrative information about the EDS file. A 
configuration tool reads this information, formats it, and displays it to the user. The user can 
also access this section with a text file viewer and display the unformatted information. This 
section requires no modification unless the user manually modifies the file. The file description 
section must contain: 


Entry Name Entry Field Data Type Required/Optional 
Keyword _| Number 


File Description Text ASCII Character Array _ | Required 


File Creation Date Required 
File Creation Time Required 
Last Modification Date Conditional 
Last Modification Time Conditional 
EDS Revision Required 


Home URL HomeURL ASCI Character Array | Optional 


The entries in the file description section provide: 


File Description Text - a single line of text displayed by the configuration tool. The 
EDS developer assigns a meaningful line of text for this entry. Double quotes enclose 
all character arrays. 


File Creation Date - the creation date of the EDS, assigned by the EDS developer. 
Provided only for convenience, you can use this date to get version information about 
the file. A configuration tool does not use this information to perform any type of 
version control, but it may display the contents. 


File Creation Time - the creation time of the EDS, assigned by the EDS developer. 
Provided only for convenience, you can use this date to get version information about 
the file. A configuration tool does not use this information to perform any type of 
version control, but it may display the contents. 
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Last Modification Date - the date of the last modification to the EDS. A configuration 
tool that allows modification of the EDS file shall update this field as needed. Provided 
only for convenience, the configuration tool displays the contents of this entry if it 
exists. If a configuration tool changes the EDS, the configuration tool shall update this 
field. However, if you modify the EDS manually or with a text editor, you should also 
update this field. 


This keyword is required if either: 
e the EDS file is modified by a software tool 
e the Last Modification Time keyword is present 


Last Modification Time - the time of the last modification to the EDS. A configuration 
tool that allows modification of the EDS file must update this entry as needed. Provided 
for convenience, the configuration tool displays the contents of this entry if it exists. Ifa 
configuration tool changes the EDS, the configuration tool must update this field. 
However, if you modify the EDS manually or with a text editor, you should also update 
this field. 


EDS Revision - the revision of the EDS. The EDS revision is not required to have any 
relationship to the product’s revision, it is simply the revision of the EDS file itself. 
The revision must be formatted as: 


major_revision.minor_revision 


Home URL - Uniform Resource Locator of the master EDS file, the Icon file and other 
files related to this EDS. The HomeURL shall specify a complete qualified URL for 
referencing a master version of the EDS file. In addition, the referenced area (without 
the file name specification) is used to specify an area where other related file(s) relating 
to the device described by this EDS are contained. 


For example: 2.1 <=major revision is 2, and minor revision is | 


$ Sample Electronic Data Sheet illustrating the File Section 


[File] 


DescText = "Smart Widget EDS File"; 

CreateDate 04-03-94; $ created 
CreateTime 17:51:44; 

ModDate = 04-06-94; $ last changed 
ModTime = 22:07:30; 

Revision = 2.1; $ Revision of EDS 
HomeURL = “http://www.odva.org/EDS/example.eds” ; 


[Device] 


[ParamClass] 
[Params] 


[Groups] 
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7-3.5.2. Device Description Section 


The Device Description section contains a manufacturer’s information about the device, 
including some of the same values in a device’s Identity Object. The table below shows the 
entries in the device description section. 


Entry Name Entry Keyword! Field Data Type Required/Optional 
Number 


Vendor ID? VendCode Required 


el 
1 
1 
1 
1 


Z 
4 


i 


U 
SCII Character Array | Required 
U Required 


, 
4 


Device Type String ProdTypeStr 1 
Product Code”? ProdCode 


ASCII Character Array | Required 


U 


Z 
4 


nN — 
Z 
4 


Required 


Minor Revision” SINT Required 


a: 
Product Name” jProdName 1 ASCII Character Array | Required 
Catalog Number ASCII Character Array | Optional 


Exclude from Adapter ExcludeFromAdap | 1 ASCII Character Array | Optional 
Rack Connection terRackConnection 


Icon File Name ASCHI Character Array | Optional 


' The SerNum and Comment entry keywords have been obsoleted 


? This entry represents an attribute of the Identity Object 


3 This entry is used to match an EDS with a specific product/revision 


The entry name for the device description field describes the unique data entry line number. A 
configuration tool uses the required entries in the device description section to match the EDS 
to the device being configured. The entries in the device description section provide: 


e Vendor ID - Numeric vendor identifier as defined by the Identity Object, Attribute 1. 

e Vendor Name - Textual vendor name. When displayed, truncation may occur to meet 
the display capabilities. 

e Device Type - Numeric device identifier as defined by the Identity Object, Attribute 2. 

e DeviceType String - Textual description of device type exactly as shown in Section 3- 
1. The string for vendor specific device types are at the vendors’ discretion. 

e Product Code - Vendor assigned numeric product code identifier as defined by the 
Identity Object, Attribute 3. Each product code shall have its own EDS. 

e Major Revision - Vendor-assigned major revision number as defined by the Identity 
Object, Attribute 4. The major revision of a product is typically incremented when 
there is a change to the form, fit, or function of the device. Changes to major revisions 
are used by a configuration tool to match a device to an EDS. 

e Minor Revision - Vendor-assigned minor revision number as defined by the Identity 
Object, Attribute 4. The minor revision number is used to identify changes in a product 
that do not effect user configuration choices. For example: firmware bug fixes, an 
additional LED, internal hardware changes, etc. Changes in minor revisions are not 
used by a configuration tool to match a device with an EDS. 
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Product Name - Textual product name as defined by the Identity Object, Attribute 7. 
When displayed, truncation may occur to meet the display capabilities. 

Catalog Number - Textual catalog or model number. One or more catalog numbers 
may be associated with a particular product code. In the case of multiple catalog 
numbers, it is still useful to provide as much of the catalog number as is practical. For 
example, 1438-BAC7xx where ‘xx’ represents variants in the catalog number supported 
by this product code/EDS. 

ExcludeFromAdapterRackConnection - This field is used to describe if a rack based 
device must be excluded from an adapter rack connection. If the field value is the string 
“Yes” this module shall be excluded from adapter rack connections by resetting the 
associated slot mask bits (input, output and configuration). If the field value is the 
string “No” or this optional field is omitted the associated slot mask bits may be set. 
Icon File Name- File name of an Icon file. Identifies a file that contain a graphical 
representation of the device. The file shall have the *. [CO MSWindows format, and 
shall minimally contain a 16x16 icon. The file may also contain 32x32, 48x48, and 
64x64 icons. The location of the Icon file is the combination of the location specified 
by the HomeURL keyword (without the HomeURL file name component) and the file 
name specified by this keyword. This keyword shall only be present when a HomeURL 
keyword exists. 


$ Sample Electronic Data Sheet illustrating the Device Description 


$ Section 
[File] 


[Device] 
VendCode 65535; 
VendName "Widget-Works, Inc."; 
ProdType = 0; 
ProdTypeStr = “Generic” ; 
ProdCode = 42; 
MajRev = 1; $ Device Major Revision 


MinRev = 1; $ Device Minor Revision 


ProdName = "Smart-Widget"; 
Catalog = “1499-DVG” ; 
Icon = “example.ico”; 
[ParamClass] 
[Params] 


[Groups] 


7-3.5.3. Device Classification 


The Device Classification section shall classify the device described by the EDS into one or 
more categories of devices. The entry keyword for all classifications shall consist of the 
character array, "Class", combined with a decimal number. The numbers shall start at 1 for the 
first class, and shall be incremented for each additional class. Commas shall separate all fields, 


and a semicolon shall indicate the end of the entry. 
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Release 1.0 


The number of fields for each classification entry shall be variable to allow a tree classification 
structure similar to a file systems directory structure. Sub-classification of the public 
classifications shall be reserved. Vendor-specific classifications may be sub-classified at the 
discretion of the vendor. The first field shall represent the highest level in the tree structure and 
shall be one of the following: 


e ControlNet; 

e DeviceNet; 

e EtherNetIP 

e avendor-specific field. 


The vendor-specific field shall begin with the Vendor ID of the company making the addition 
followed by an underscore (VendorID_VendorSpecificField). The VendorID shall be displayed 
in decimal and shall not contain leading zeroes. Each vendor is responsible for maintaining 
and documenting their vendor-specific field. 


Parameter Class Section 


The parameter class section: 


e identifies the class level attributes of the configuration parameters described by the EDS 
e contains a subset of the Parameter Object class attributes as defined in the CIP Object 
Library 


The following table shows the predefined format and legal range of fields in the parameter 
class section: 


Entry Name Entry Field Data Type Required/Optional 
Keyword Number 


Max Instances MaxInst UINT Required 
Parameter Class Descriptor | Descriptor WORD Required 


Configuration Assembly CfgAssembly | 1 UINT Required 
Instance 


The CIP Object Library provides more specific details about the parameter fields, including the 
allowed data types and lengths. In general, the EDS parameter fields provide: 


e Max Instances - Identifies the total number of configuration parameters contained in 
the device associated with the EDS 

e Parameter Class Descriptor - Contains bit flags that describe the behavior of the 
device’s parameter objects 

e Configuration Assembly Instance - Identifies the configuration assembly object 
instance number for parameters associated in this EDS and defined in the CIP Object 
Library 
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$ Sample Electronic Data Sheet illustrating the Parameter Class Section 
[File] 
[Device] 
[ParamClass] 
MaxInst = 3; 
Descriptor = 0x0E; 
CfgAssembly = 3; 


[Params ] 


[Groups] 


7-3.5.5. Parameters Section 
The parameters section identifies all of the configuration parameters in a device. All 
configuration performed on a device depends on the configuration parameters. 
The parameter section shall identify the configuration parameters in a device. The entry 
keyword shall be one of the following character arrays, “Param”, “ProxyParam’”, 
“ProxiedParam”, combined with the Parameter object instance number (decimal) for the 
device, e.g. “Param1”. When a parameter object instance exists within a node, and if this 
parameter is also described within an EDS, then the value of “N” in “ParamN” shall be equal 
to the parameter object instance. The actual parameter object instance may, but need not be, 
implemented in the device. Conversely, it is not required that ALL parameter object instances 
have a corresponding “ParamN” entry in an EDS. Commas shall separate all fields, and a 
semicolon shall indicate the end of an entry. A white space or nothing between commas shall 
be used for optional fields not provided. Each entry contains the formatted fields shown in the 
table below. The “ProxyParam’and “ProxiedParam” keywords are defined further in 7-3.6, 
Modular EDS File Requirements. 
Field Name Required/Optional 

Reserved Required 

Link Path Size Required 

Descriptor Required 

Data Size fo fusInt —Reuired 

Parameter Name Required 

Units String Iss ASC. Character Array_| Required 

Minimum Value Required 

Maximum Value Required 

Default Value 2s datatypes Required 

Scaling Multiplier 13s {uINT. ss Optional 

Scaling Divider 4S UINT Optional 

Scaling Base ee [ec Optional 
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Field Name Field Number Data Type Required/Optional 
r 


Scaling Offset Optional 
Multiplier Link Optional 
Divisor Link Optional 
Base Link Optional 
Offset Link Optional 


Decimal Precision 1 USINT Optional 


The CIP Parameter Object definition provides more specific details about the parameter fields, 
including the allowed data types and lengths. In general, the EDS parameter fields provide: 


e Reserved - This first field shall contain a zero. 

e Link Path Size - The number of bytes used to represent path. 

e Link Path - The link path identifier. The path shall be entered as a character array, 
using the path notation described in Section 4—-3.4.8. If the attribute described by this 
ParamN entry is not directly addressable from the network, this field shall be empty. If 
this field is a null string, “°’, it shall be addressable as the data attribute (instance 
attribute 1) of the Nth instance of the Parameter object. 

e Descriptor - The parameter descriptor. 

e Data Type - The data type identifier. 

e Data Size -The numeric data size value in bytes. 

e Parameter Name - The textual parameter name. If necessary, truncation of the 
retrieved text occurs to meet the maximum character array length allowed. 

e Units String - The textual display units character array. If necessary, truncation of the 
retrieved text occurs to meet the maximum character array length allowed. 

e Help String - The textual help character array. If necessary, truncation of the retrieved 
text occurs to meet the maximum character array length allowed. 

e Minimum Value - The minimum numeric value that may be assigned to the parameter 
data value. 

e Maximum Value - The maximum numeric value that may be assigned to the parameter 
data value. 

e Default Value - The default numeric value assigned to the parameter data value. 

e Scaling Multiplier - The numeric multiplier value applied to the current parameter data 
value. 

e Scaling Divider - The numeric divisor value applied to the current parameter data 
value. 

e Scaling Base - The numeric base value applied to the current parameter data value. 

e Scaling Offset - The numeric offset value applied to the current parameter data value. 

e Multiplier Link - The Parameter Object instance that contains the numeric multiplier 
value to apply to the current parameter data value. 

e Divisor Link - The Parameter Object instance that contains the numeric divisor value to 
apply to the current parameter data value. 

e Base Link - The Parameter Object instance that contains the numeric base value to 
apply to the current parameter data value. 

e Offset Link - The Parameter Object instance that contains the numeric offset value to 
apply to the current parameter data value. 

e Decimal Precision - The numeric precision value applied to the current parameter data 
value. 
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The “Enum” keyword shall be used to provide an enumeration list of parameter choices to 
present to the user. The entry keyword for all enumerated parameters shall consist of the 
character array, “Enum”, combined with the decimal number from the corresponding Param 
entry. Commas shall separate all fields, and a semicolon shall indicate the end of the entry. 
Each Enum entry shall consist of pairs of integers and strings. 


$ Sample Electronic Data Sheet illustrating the Parameters Section 
[File] 


[Device] 
[ParamClass] 


[Params ] 
Paraml 0, 1,"20 02", Ox0E94, 1, 1,"Preset","V","User Manual p33", 
0, 5, 1, 1, 1, 1, 0, 0, 0, 0, 0, 2; 


parameter instance 

First field shall equal 0 

path size, path 

descriptor - in hex format 

data type 

data size 

name 

units 

help string 

min, max, default data values 
mult, div, base, offset scaling 
mult, div, base, offset links not used 
decimal places 


04 24 01 30 03", 


"Trigger", 
"HZ W j 
"User Manual p49", 


$ 
$ 
$ 
$ 
$ 
$ 
$ 
$ 
$ 
$ 
$ 
$ 
$ 


$ not addressable from link 
0x0082, 8, 1, "speed control", "", "", 3, 12, 3, y;yrrrrrrit 


“stops, -8,.. “slow, rk2y. “fast; 


[Groups] 


7-3.5.6. | Parameter Groups Section 


The parameter groups section identifies all of the parameter groups in a device. Each parameter 
group contains a list of the parameter object instances in the group. The entry keyword for each 
group consists of the combination of the character array, “Group”, and the Parameter Group 
instance number (decimal) in the device, for example “Group1”. The decimal numbers must 
start at one and increment by one. 


The fields in each entry contain the group name, the number of members in the group, and the 


instance numbers of the parameter objects in the group. A comma separates all fields, and a 
semicolon indicates the end of the entry. The parameter group section contains: 
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Field Name Field Number Data Type Required/Optional 


7-3.5.7. 


Release 1.0 


Group Name String 


Number of Members 


Parameter 


2 
3 thru (number of | UINT Required 
members + 2) 


$ Sample Electronic Data Sheet illustrating the Parameter Groups Section 
[File] 
[Device] 


[ParamClass] 


[Params ] 


[Groups] 
Group1 "Setup", 2, 1, 2; $ group 1 
Group2 "Monitor", 2, 2, 3; $ group 2 
Group3 "Maintenance", 2, 1, 3; $ group 3 


Assembly Section 


The Assembly section describes the structure of a data block. Often this block is the data 
attribute of an Assembly object; however, this section of the EDS can be used to describe any 
complex structure. The description of this data block parallels the mechanism that the 
Assembly object uses to describe its member list. 


The "Revision" entry keyword shall have one 16-bit integer field that shall be the revision 
(class attribute 1) of the Assembly object within the device. If this optional entry is missing, 
the revision of the Assembly object shall be 2. 


The entry keyword for all assemblies shall consist of one of the following character arrays, 
“Assem”, “ProxyAssem”, “ProxiedAssem” combined with the Assembly object instance 
number (decimal) for the device, e.g. “Assem1”. Ifa particular instance of the Assembly 
object is addressable from the link, there shall be a one-for-one pairing between the Assem 
number in the EDS file and the Assembly instance number in the device. Commas shall 
separate all fields, and a semicolon shall indicate the end of the entry. A white space or 
nothing between commas shall be used for optional fields not provided. The “ProxyAssem’and 
“ProxiedAssem” keywords are defined further in 7-3.6, Modular EDS File Requirements. 


Each entry shall contain the formatted fields shown in Table 7-3.1. 
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Table 7-3.1. AssemN Keyword format 


Field name Data type Required/ 
Optional 
Name 1 Eds_Char_Array Optional 
Reserved 


Member Size 7,9, 11... UINT Conditional 


Member 8, 10,12... AssemN, ParamN, Conditional 
Reference Number, or EPATH 


The first field, called "Name", shall be a string giving a name to the data block. This optional 
field may be used by a user interface. 


The second field, called "Path", shall be a string that specifies a logical path. This path shall 
identify the address of the data block within the device. If the block described by this AssemN 
entry is not directly addressable from the link, this field shall be empty. If this field is a null 
string, “”’, the data block shall be addressable as the data attribute (instance attribute 3) of the 
Nth instance of the Assembly object. 


The third field, called "Size", shall be the size of the data block in bytes. Either this field of the 
“Member Size”’/”,Member Reference” fields shall be present. Both of these fields may be 
present; however, since they both specify the size of the buffer, the sizes specified by both 
means shall agree. 


The fourth field, “Descriptor”, shall be a bit-field that describes certain properties of the 
Assembly. The bits of this field can be interpreted as follows: 


Bit Meaning 

0 Allow Value Edit | If this bit is set (1), the contents of the Assembly’s value member 
references can be edited. If reset (0), the contents of these member 
references may not be edited. The member references considered to be 
values are a Number and a Data Segment EPATH. If this field is 
empty, the meaning shall default to reset (0). 
1-15 Reserved 


Fields 5 and 6 shall be reserved for future definition and shall be empty. 


The remaining fields shall be paired such that a "Member Size" field is paired with a "Member 
Reference" field making the total number of fields even. The pairs shall correspond to an 
Assembly object member list. 


The allowed entries for the "Member Reference" field shall be one of the following: 


e aParamN entry from the [Params] section; 

e an AssemN entry from the [Assembly] section; 
e astring representing a path (EPATH); 

e anumber, maximum value 2°; 

e anempty field; 
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If the "Member Reference" field is empty, the number of bits specified by the "Member Size" 
field shall be used as a pad within the Assembly object. A "Member Reference" field 
containing a null string shall be treated as if the field was empty. A "Member Reference" field 
and its corresponding "Member Size" shall not both be empty. The member reference 
specifying an EPATH shall consist of either Logical or Data Segments. 


The "Member Size" field shall have units of bits. If a "Member Size" field is empty, the 
defined size of the corresponding "Member Reference" field shall be used. The defined size of 
a Param entry shall be as given in its 6" field (size). The defined size of an Assem entry shall 
be as given in its 3" field (size). 


The members shall be placed into the data block least significant bit first just as they are in the 
Assembly object. Ifa "Member Size" field is smaller than the defined size of the 
corresponding "Member Reference" field, the least significant bits of the corresponding 
"Member Reference" field shall be used. If a "Member Size" field is larger than the defined 
size of the corresponding "Member Reference" field, the entire member shall be followed by 
zero pads to extend the member to the "Member Size". The data block represented shall be an 
integer number of bytes. The total of all member sizes shall equal the AssemN Size field 
(when expressed as bits). 


For example, Assem5 in Figure 7-3.2 shall be | byte long and have a default value of 0x21. 


Figure 7-3.2. [Assembly] section example 


{Params ] 
Paraml = 
0, S$ first field shall equal 0 
6, "20 OF 24 01 30 01", S$ path size, path 
0x0000, S$ descriptor 
2, S$ data type : 16-bit WORD 
2, S$ data size in bytes 
"Tdle state", S$ name 
as S$ units 
"User Manual p48", S$ help string 
0; 2;. L, S$ min, max, default data values 
Or Oe MOS. JOY S$ mult, dev, base, offset scaling not used 
04505052 305 S$ mult, dev, base, offset link not used 
0; S$ decimal places not used 


Param2 = 0, 6, "20 OF 24 02 30 01", $ path size, path 
0x0000, 2, 2, 
"Fault state", "", "User Manual p49", 
0, 2, 2, 0, 0, 0, 0, 0, 0, O, 0, OF 


[Assembly] 
Revision = 2; 
Assem5 = "configuration", "20 04 24 05 30 03",1,,,, 


4, Paraml, 
3, Param2, 
1, ; 
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7-3.5.8. | Complete Electronic Data Sheet Example 


A complete Electronic Data Sheet example is given below which is a compilation of the section 
examples given throughout this chapter. 


$ Complete Electronic Data Sheet Example 

[File] 

DescText = "Smart Widget EDS File"; 

CreateDate = 04-03-94; $ created 
CreateTime = 17:51:44; 

ModDate = 04-06-94; $ last changed 
ModTime = 22:07:30; 

Revision = 2.1; $ revision of EDS 


[Device] 

VendCode 65535; 

VendName "Widget-Works, Inc."; 
ProdType = 0; 

ProdTypeStr = "Generic"; 
ProdCode 

MajRev = 

MinRev 


ProdName "Smart-Widget"; 
Catalog = "1499-DVG"; 
[ParamClass] 
MaxInst = 3; 
Descriptor = 0x0E 


CfgAssembly = 3; 

[Params] 
Paraml = 0, 1,"20 02", Ox0E94, 1, 1,"Preset","V","User Manual p33", 
0, 5, 1, 1, 1, 0, 0, O, 


parameter instance 

First field shall equal 0 
1, "20 04", path size, path 
0x0A94, 

1, 

1, 
“Trigger”, 


descriptor - in hex format 
data type 

data size 

name 

units 

Manual p49”, help string 

min, max, default data values 

mult, div, base, offset scaling 

mult, div, base, offset links not used 
decimal places 


ununrn un nnn Yn Un nH UH UH 


[Groups] 
Groupl = "Setup", 2, ; $ group 1 
Group2 "Monitor", H $ group 2 
Group3 "Maintenance", ; $ group 3 


7-34 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Chapter 7: Electronic Data Sheets 


7-3.5.9 


Release 1.0 


Connection Manager Section 


The Connection Manager section shall contain information concerning the number of types of 
application connections a device supports. Each entry keyword shall be one of the following 
character arrays, “Connection”, “ProxyConnect”, “ProxiedConnect”, combined with a 
number (decimal), for example, “Connection1”, “ProxyConnect1”, or “ProxiedConnect1”. 
The decimal numbers shall start at 1 and increment for each additional “Connection” entry. The 
decimal number shall not be required to start at 1 or increment for each additional 
“ProxyConnect” or “ProxiedConnect” entry. Commas shall separate all fields, and a 
semicolon shall indicate the end of the entry. A white space or nothing between commas shall 
be used for optional fields not provided. The “ProxyConnect’and “ProxiedConnect” keywords 
are defined further in 7-3.6, Modular EDS File Requirements. 


Each entry shall contain the formatted fields shown in Table 7-3.3. 


Table 7-3.3. Connection Manager section format 


Field name aes Data type Required/Optional 
Trigger and transport 1 DWORD Required 
Connection parameters 2 DWORD Required 
O=>T RPI 3 UDINT or Param | Optional 
OST size 4 UINT or Param | Conditional 
O=>T format 5 Param or Assem | Conditional 
T>0 RPI 6 UDINT or Param | Optional 
T=>0 size 7 UINT or Param | Conditional 
T=>0 format 8 Param or Assem_ | Conditional 
config #1 size 9 UINT or Param | Optional 
config #1 format 10 Param or Assem | Optional 
config #2 size 11 UINT or Param | Optional 
config #2 format 12 Param or Assem | Optional 
Connection name string 13 Eds_ Char Array | Required 
Help string 14 Eds Char Array | Required 
Path 15 Eds_Char_Array | Required 


Trigger and transport mask 


The bit assignments for the trigger and transport mask shall be as shown in Table 7-3.4. A bit 
shall be set to a 1 (on) for each trigger mode the connection supports. All other bits shall be set 
to a 0 (off). For the client/server bit: 0=client, 1=server. Only one of the transport types shall 
be set to a 1 (on). 
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Table 7-3.4. Trigger and transport mask bit assignments 


Bit Bit definition 
0 class 0: null 

1 class 1: duplicate detect 
2 class 2: acknowledged 
3 class 3: verified 
4 

5 


class 4: non-blocking 
class 5: non-blocking, fragmenting 
6 class 6: multicast, fragmenting 
7-15 _| class: reserved 
16 trigger: cyclic 
17 trigger: change of state 
18 trigger: application 
19-23 | trigger: reserved 
24 transport type : listen-only 
25 transport type : input-only 
26 transport type : exclusive-owner 
27 transport type : redundant-owner 
28-30 | reserved 
31 client = 0 / server = 1 


Connection parameters 


The bit assignments for the connection type and priority mask shall be as shown in Table 7-3.5. 
A bit shall be set to a 1 (on) for each connection type and priority the connection supports. All 
other bits shall be set to a 0 (off). 


Table 7-3.5. Connection parameters bit assignments 


Bit Bit definition 
0 OST fixed size supported 
1 OST variable size supported 
2 T=0 fixed size supported 
3 T=>0 variable size supported 
4-5 O=>T number of bytes per slot in the O=>T real time data packet for 


adapter rack connections. 
0=1 byte 
1 =2 bytes 
2 =4 bytes 
3 = 8 bytes 


6-7 T=>O number of bytes per slot in the T=>O real time data packet for 
adapter rack connections. 

0 = 1 bytes 

1 =2 bytes 

2 =4 bytes 

3 = 8 bytes 


8-10 |O=T Real time transfer format. 

0 = connection is pure data and is modeless. 

1 = Use zero data length packet to indicate idle mode. 
2 = reserved 

3 = heartbeat 

4 = 32-bit run/idle header 

5 thru 7 are reserved 


11 reserved 
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Bit Bit definition 

12—14 | T>0 Real time transfer format 
0 =connection is pure data and is modeless. 
1 = Use zero data length packet to indicate idle mode 
2 = reserved 
3 = heartbeat. 
4 = 32-bit run/idle header 
5 thru 7 are reserved 

15 reserved 

16 O=T connection type: NULL 

17 O=T connection type: MULTICAST 

18 O=T connection type: POINT2POINT 

19 O=T connection type: reserved 

20 T=0 connection type: NULL 

21 T=>0 connection type: MULTICAST 

22 T=0 connection type: POINT2POINT 

23 T=>0 connection type: reserved 

24 OST priority: LOW 

25 OST priority: HIGH 

26 O=T priority: SCHEDULED 

27 OST priority: reserved 

28 T=>0 priority: LOW 

29 T>0 priority: HIGH 

30 T=0 priority: SCHEDULED 

31 T=>0 priority: reserved 

O>T RPI 


The OST RPI shall be the number of microseconds of the requested packet interval. The 
O=T RPI shall be a UDINT or a Param entry from the [Params] section that evaluates to a 
UDINT. If this field is empty, no constraints are placed on the OST RPI. 

O=>T size 


The O>T size shall be the number of bytes delivered to the target transport. It shall not 
include the transport sequence count. The OST size shall be a UINT or a Param entry from 
the [Params] section that evaluates to a UINT. If this field is empty, the defined size of the 
O=T format shall be used after the optional run/idle header size is added. 


O=>T format 


The O>T format entry shall define the structure of the consumer buffer for this connection. 
Valid format descriptors shall be identifiers within the EDS file including 


a Param entry from the [Params] section; 


an Assem entry from the [Assembly] section. 
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This field may be empty indicating that the consuming format is not specified. This field shall 
not be empty if the OST size field is empty. The O>T format shall not include the 32-bit 
run/idle header if it is present. 


T=>O RPI 


The T>O RPI shall be the number of microseconds of the requested packet interval. The 
T=>O0 RPI shall be a UDINT or a Param entry from the [Params] section that evaluates to a 
UDINT. If this field is empty, no constraints are placed on the T>O RPI. 


T=0O size 


The T=>0 size shall be the number of bytes produced by the target transport. It shall not 
include the transport sequence count. The T=>0 size shall be a UINT or a Param entry from 
the [Params] section that evaluates to a UINT. If this field is empty, the defined size of the 
T=0 format shall be used after the optional run/idle header is added. 


T=0 format 
The TO format shall define the structure of the producer buffer for this connection. Valid 
format descriptors shall be identifiers within the EDS file including 

a Param entry from the [Params] section; 


an Assem entry from the [Assembly] section. 


This field may be empty indicating that the producing format is not specified. This field shall 
not be empty if the T>0 size field is empty. The format shall include the status header if it is 
present. 


Configuration 


The config #1 size and config #2 size shall specify the size of the optional data segment that is 
appended to the path in the Forward_Open. The data segment shall be the concatenation of the 
two buffers described by the config #1 format and config #2 format. The sizes shall be the 
number of bytes and shall be a UINT or a Param entry from the [Params] section that evaluates 
to a UINT. If one of the config size fields is empty, the natural size of the corresponding 
config format field shall be used. 


Valid config format fields shall be identifiers within the EDS file including 

a Param entry from the [Params] section; 

an Assem entry from the [Assembly] section. 
The config format fields may be empty indicating that the config format is not specified. If 
both the config size and config format fields are empty, no data segment shall be appended to 


the path of the Forward Open. 


Connection name string 


A tool may display the connection name string (character array). The connection name string 
shall be unique among all Connection entries within the EDS. 
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Help string 


A tool may display the textual help character array. If no help string is to be provided a “null” 
string shall be used where a null string is defined as two double quotations: “” with no 
characters between the quotation marks. 


Path 


A path referencing the target object. The path shall be entered as a CIP Path (character array). 
In addition, the path field may also contain the other following references: 


Param entries from the [Params] section; 


e the keyword SLOT; 
e the keyword SYMBOL_ANSI; 
e the keyword SLOT MINUS ONE. 


The Param entries shall evaluate to a USINT, UINT or UDINT. The value of the Param shall 
be used in a little endian order for insertion into the path. The Param references within the path 
may be enclosed in brackets as shown in. When enclosed in brackets, the value of the Param 
shall be local to the path — the same Param entry may have a different value elsewhere in the 
EDS. Ifthe Param is not enclosed in brackets, the value shall be the same everywhere within 
the EDS. The keyword, SLOT, shall always evaluate to a USINT. The values substituted for 
the SLOT keyword shall correspond to the position of a module in a back-plane. The keyword, 
SLOT_MINUS_ONE, shall always evaluate to a USINT. The values substituted for the 

SLOT MINUS _ ONE keyword shall correspond to the position of a module in the back-plane 
minus 1. The keyword, SYMBOL_ANSI, shall evaluate to an extended symbolic segment (see 
Appendix C) entered through the user interface. The extended symbol segment shall be an 
ANSI extended symbol (CIP path type = 0x91). For example, the string "CAB" shall evaluate 
to the following extended symbol segment (padded): 0x91 0x03 0x43 0x41 0x42 0x00. 
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Figure 7-3.6. [Connection Manager] section example 


[Params ] 

Paraml = 
0, Tv vy 
0x0004, 
8, 1, 
"Read", 
64, 95, 64, 
Ly chp, =63; 
0, 0, 0, Oy, 0; 


Param2 = 

0, v , 

0x0004, 

8, 1, 

"Write", 

160, 191, 160, 
dp dey, sly 1-5.9, 
Oy: 804 O44 Op ~O% 


[Connection Manager] 
Connectionl = 
0x04010002, 


0x44244401, 


1, 16, lA 
tr 12, , 


, , 


T T 
"read/write", 


wee 


"20 04 24 01 2C 


S$ specifies read buffer 
S$ no path means not directly accessible 
S descriptor support scaling 
S USINT, 1 byte 
S name 
S units & help string 
S$ min, max, default data values 
S$ mult, div, base, offset scaling 
S mult, div, base, offset link & decimal 
$(not used) 
S specifies write buffer 
S$ no path means not directly accessible 
S descriptor support scaling 
S USINT, 1 byte 
S name 
S units & help string 
S min, max, default data values 
S$ mult, div, base, offset scaling 
S mult, div, base, offset link & decimal 
S(not used) 
S trigger & transport 
S class 1, cyclic, exclusive-owner 
S point/multicast & priority & realtime format 
S fixed, 32-bit headers, scheduled, 
$ O=>T point-to-point, T=>0O multicast 
S O=>T RPI, size, format 
S$ T=>O RPI, size, format 
S config part 1 (not used) 
S$ config part 2 (not used) 
S$ connection name 
S Help string 
[Param2] 2C [Paraml1]"; 
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Port Section 


The Port section shall describe the CIP ports available within a device. Every CIP shall have a 
corresponding entry in this section. The entry keyword for all ports shall consist of the 
character array “Port”, combined with a decimal number corresponding to an instance of the 
port object. For example, Port] is instance 1 of the Port Object. A white space or nothing 
between commas shall be used for optional fields not provided. 


Field Name Field number Data type Required/Optional 


Port Type Name Field Keyword Required 


Port Name Optional 
Port Object Optional 
Port Number Required 
Reserved ,6 Not Used 
Port Specific 5 Byxes Port Specific 


The first field, called “Port Type Name”, shall be one of 


ControlNet 
ControlNet_Redundant 
TCP! 

DeviceNet 


A vendor-specific value beginning with the device’s Vendor ID and an underscore character 
(65535_’) 


' This shall indicate an EtherNet/IP capable TCP port. 


[Port] 

Portl = DeviceNet, 

“Port A”, name of port 

“20 03 24 01”, instance one of the DeviceNet object 
2; port number 2 


Port2 = 65535 Chassis, 

“Chassis”, $ name of port 

“20 9A 24 01”, $ vendor specific back-plane object 
1; $ port number 1 


The optional “Name” field shall be a string giving a name to the port, and may be used by a 
user interface. The “Port Object” field shall be a path that identifies the object associated with 
the port. 


The port number | shall correspond to the back plane “port”. Devices with a back plane that 
can not send CIP messages shall not have a port number 1. 


Modular EDS File Requirements 


This section describes the concept and contents of a Modular EDS and specifies the usage 
requirements. 
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7-3.6.1. Modular Section 


The [Modular] section shall describe a chassis based system. The two types of modular devices 


shall be: 


Chassis; 
Module. 


A [Modular] section that describes a chassis shall contain a required keyword 


“DefineSlotsInRack” as shown in Figure 7-3.7. The single field on this entry shall be a 16-bit 
unsigned integer (UINT) indicating the number of slots in the chassis. Even though an 
electronic key is defined for the chassis, it need not be addressable from the link. The SLOT 
keyword used in path definitions in the [Connection Manager] section shall range from 0 to the 
number of slots minus |. The keyword “SlotDisplayRule” is optional. The single field on this 
entry shall be a parameter from the [Params] section (ParamN) which defines the translation 


between internal and external slot number. 


Figure 7-3.7. [Modular] section describing a chassis 


[File] 
DescText = "Wonder Chassis EDS file"; 
CreateDate = 09-01-1997; 
CreateTime = 17:23:00; 
Revision = 1.1; 
[Device] 
VendCode = 65535; 
VendName = "Widget Works, Inc."; 
ProdType = 101; 
ProdTypeStr = "Widget Works Generic"; 


ProdCode = 1; 
MajRev = 1; 
MinRev = 1; 
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ProdName "Widget Chassis"; 
Catalog = "1234-chassis"; 
[Params] 

Paraml = 
0, S first field shall equal 
pa S path size,path 
0x0004, S descriptor 
8, S$ data type: 32-bit Unsigned Long Integer 
Ley S$ data size in bytes 
"Slot Naming Convention", S name 
TO S units 
ee S help string 
0,4,0, S min,max,default data values 
0,0,0,0, S mult,dev,base,offset scaling 
0,0,0,0, S mult,dev,base,offset link not used 
O; S decimal places not used 

Enuml = 


Oesin Ka pl MOM 2 aNa 3 ED Ae as 


[Modular] 


DefineSlotsInRack = 5; 
SlotDisplayRule = Paraml; 


A [Modular] section that describes a module shall contain the "Width" and "Rack" entries. 
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The required entry with the keyword "Width" shall have a single field that indicates how many 
slots of the chassis are consumed by the module. The field shall be a 16-bit unsigned integer 
(UINT). 


The entry keyword for all chassises, into which the module can be placed, shall consist of the 
character array, "Rack", combined with a decimal number. The numbers shall start at 1 for the 
first chassis, and shall be incremented for each additional chassis. Commas shall separate all 
fields, and a semicolon shall indicate the end of the entry. The fields for the "Rack" entries 
shall be as shown in Table 7-3.8. 


Table 7-3.8. Field for the Rack entry keyword 


Field name Field number Data type Required/Optional 

Vendor ID 1 UINT Required 
Product Type 2 UINT Required 
Product Code 3 UINT Required 
Major Revision 4 USINT Required 
Minor Revision 5 USINT Required 
reserved 6, 7, 8 empty not used 

Legal Slot 9,10, 11... UINT Required 


The "Vendor ID", "Product Type", "Product Code", "Major Revision" and "Minor Revision" 
field shall identify the electronic key of the chassis into which the module may be placed. The 
reserved field shall be empty. The "Legal Slot" fields shall identify the slots into which the 
module may be placed. The EDS for the module shall contain one "Rack" entry for each 
chassis into which the module may be placed as shown in Figure 7-3.9. 


Figure 7-3.9. [Modular] section describing a module with a network connection 


[Modular] 
Width = 1; 
Rackl = $ this module can only plug into 
65535, 101, 1, 1, 1,,,, $ slot 0 of this five slot chassis 
0; 


Rack2 = 65535, 101, 2, 1, 1,,,, 
0; 


Modular Additions to Basic EDS Sections 
Additions to the Modular Section 


A [Modular] section that describes a module that does not have a link addressable Identity 
object may contain the entry keyword "ExternalID". The keyword shall have a single field. 
This field shall be a byte string that identifies the module. Modules that may be placed into 
slot 0 shall have an addressable Identity object and shall have no "ExternalID" entry. 
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A [Modular] section that describes a module that has a link connection and can be placed in 
slot 0 may contain the keyword “GenericID”. The keyword shall have a single value. This 
field shall be a byte string that shall be included in the data segment for a module connection in 
place of the ExternalID when no module keying is desired. 


A [Modular] section that describes a module that has a link connection and can be placed in 
slot 0 may contain the keyword “ExternIDExactMatch”. The keyword shall have a single 
value, Yes or No. Yes shall indicate that the ExternalID specifies one specific device, No shall 
indicate that the ExternalID specifies one of a set of compatible devices. If the 
“ExternIDExactMatch” does not exist the default condition shall be that the ExternalID 
specifies one specific device. 


A [Modular] section that describes a module that has a link connection and can be placed in 
slot 0 may contain the entry keyword “Query”. This keyword shall have 4 fields. The first 
field shall be a path that identifies a link addressable attribute that contains an array of external 
identifiers: one for each slot in the chassis except slot 0. The second field shall be the service 
to use with the query path (i.e. 1 — get attribute all or 14 — get attribute single). The third field 
shall be an integer that determines the number of bytes used to identify each module and shall 
be in the range | to 16. Ifa double slot module is in the chassis, the external identifier for the 
module shall appear twice in the array returned from a query. A query shall only be address to 
a module in slot 0. The fourth field shall be the ExternalID returned when an empty slot exists. 


Figure 7-3.10. [Modular] section describing a module without an Identity object 


[Modular] 
Width = 1; 
Rackl = S$ this module can plug into 
65535;,~ LOLy* ayy Ly: Liga SS oSilbote: L, (2,3 andr4 of 
Vi Zip (By 4G S$ this five slot chassis 
Rack2 = 


699397 LO0dy 25-1, Lives 
Vis Zig Op Aye Dp OG: PE 


Query = “20 04 24 07 30 03”,1,2,”FFEF FF”; 


ExternalID = “12 34”; 


GenericID = “00 00”; 


ExternalIDExactMatch = No; 
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Additions to the Parameter Section 


The “ProxyParam” and “ProxiedParam” keywords shall be used to describe parameters that 
are proxied by a ControlNet adapter device to another device that does not support the CIP 
protocol. An example of this is a ControlNet adapter module (the device proxying the 
connection) in a multiple slot I/O rack with an analog I/O module (the device the connection is 
proxied for). 


The “ProxyParam” shall exist in the EDS for the device that performs the proxy. 


The “ProxiedParam” keyword shall exist in the EDS for the device that the proxy is 
performed for. 


The information in the [Modular] section shall be used to associate EDS files containing 
“ProxyParam” keywords to EDS files containing “ProxiedParam” keywords. This 
association shall exist when both EDS files specify a matching Rack entry. 


The decimal number (that is combined with “ProxyParam” and “ProxiedParam’’) shall be 
used to match a “ProxyParam” to a “ProxiedParam”. The field values of a matched 
“ProxyParam” and “ProxiedParam” pair shall be combined to constitute the same field value 
information that exists in a single “Param” entry. This combination shall be done by using the 
field value from the “ProxyParam” unless that field value is the keyword “Module”. When 
the field value specified in the “ProxyParam” is “Module” the field value specified in the 
“ProxiedParam” shall be used. It shall be legal to specify field values for “ProxiedParam” 
entries whose corresponding field value in the “ProxyParam” is not “Module”, however, 
these field value shall not by used, they shall exist only for documentation. 


Another keyword may also exist in the [Params] section. This keyword shall be used to 
provide minimum, maximum and default values to be added to the “ProxyParam” minimum, 
maximum and default values. This entry keyword shall be “ProxyParamSizeAdder’”, 
combined with the decimal number from the corresponding “ProxyParam” entry. Commas 
shall separate all fields, and a semicolon shall end the entry. Each “ProxyParam” entry shall 
consist of a Minimum Value, Maximum Value and Default Value fields. The definition of 
these fields matches the “Param” definitions. The “ProxyParamSizeAdder” keyword 
provides a means for an adapter on a module connection (“ProxyConnect’) to add adapter data 
to the module data and return the combined data on the connection. 


Another keyword may also exist in the [Param] section that corresponds to the “ProxyParam”, 
“ProxyEnum”. “ProxyEnum” has the same definition as “Enum” except it is associated with 
“ProxyParam” instead of “Param”. A second keyword may also exist in the [Param] section 
that corresponds to the “ProxiedParam”, “ProxiedEnum”. “ProxiedEnum” has the same 
definition as “Enum” except it is associated with “ProxiedParam” instead of “Param”. 
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The following entries are additional values allowed for the "Member Reference" field within 
the Assembly section: 


ExternalID; 
InputSlotMask0; 
InputSlotMask1; 
OutputSlotMask0; 
OutputSlotMask1; 
ConfigSlotMask0; 
ConfigSlotMask1. 


The “ExternalID” keyword shall indicate the usage of the device “ExternalID” value in the 
case when device keying is desired or the “GenericID” value in the case when module keying 
is not desired. 


The “InputSlotMask0” keyword shall indicate the location of the input slot mask in the 
assembly. The preceding size field shall be required. An input slot mask is an array of bits 
which represents inclusion or exclusion of a modules target to originator data in this adapter 
rack connection. Bit 0 in this array represents slot 0, bit | represents slot 1, etc. 


The “InputSlotMask1” keyword shall indicate the location of the input slot mask in the 
assembly. The preceding size field shall be required. An input slot mask is an array of bits 
which represents inclusion or exclusion of a modules target to originator data in this adapter 
rack connection. Bit 0 in this array represents slot 1, bit 1 represents slot 2, etc. 


The “OutputSlotMask0” keyword shall indicate the location of the output slot mask in the 

assembly. The preceding size field shall be required. An output slot mask is an array of bits 
which represents inclusion or exclusion of a modules originator to target data in this adapter 
rack connection. Bit 0 in this array represents slot 0, bit 1 represents slot 1,etc. 


The “OutputSlotMask1” keyword shall indicate the location of the output slot mask in the 

assembly. The preceding size field shall be required. An output slot mask is an array of bits 
which represents inclusion or exclusion of a modules originator to target data in this adapter 
rack connection. Bit 0 in this array represents slot 1, bit 1 represents slot 2 etc. 


The “ConfigSlotMask0” keyword shall indicate the location of the configuration slot mask in 
the assembly. The preceding size field shall be required. A configuration slot mask is an array 
of bits which represents inclusion or exclusion of a modules configuration data in the fwd_open 
of this adapter rack connection. Bit 0 in this array represents slot 0, bit 1 represents slot 1, etc. 


The “ConfigSlotMask1” keyword shall indicate the location of the configuration slot mask in 
the assembly. The preceding size field shall be required. A configuration slot mask is an array 
of bits which represents inclusion or exclusion of a modules configuration data in the fwd_open 
of this adapter rack connection. Bit 0 in this array represents slot 1, bit 1 represents slot 2, etc. 
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The “ExternalID” combined with a number (decimal) keyword intended purpose is to allow 
individual device keying for adapter rack connections. It shall indicate the usage of the device 
“ExternalID” value in the case when device keying is desired or the “GenericID” value in the 
case when module keying is not desired. The decimal number specifies the slot of this 
“External[D”. 


The “ProxyAssem” and “ProxiedAssem” keywords shall be used to describe assemblies that 
are proxied by a CIP adapter device to another device that does not support the CIP protocol. 
An example of this is a ControlNet adapter module (the device proxying the connection) in a 
multiple slot I/O rack with an analog I/O module (the device the connection is proxied for). 


The “ProxyAssem” keyword shall exist in the EDS for the device that performs the proxy; the 
“ProxiedAssem” keyword shall exist in the EDS for the device that the proxy is performed for. 


The information in the [Modular] section shall be used to associate EDS files containing 
“ProxyAssem” keywords to EDS files containing “ProxiedAssem” keywords. This 
association shall exist when both EDS files specify a matching Rack entry. 


The decimal number (that is combined with “ProxyAssem” and “ProxiedAssem’’) shall be 
used to match a “ProxyAssem” to a “ProxiedAssem”. The field values of a matched 
“ProxyAssem” and “ProxiedAssem” pair shall be combined to constitute the same field value 
information that exists in a single “Assem” entry. This combination shall be done by using the 
field value from the “ProxyAssem” unless that field value is one of the keywords “Module” or 
“ModuleMemberList”. When the field value specified in the “ProxyAssem” is “Module” the 
field value specified in the “ProxiedAssem” shall be used. The field value “Module” shall not 
be used for “Member Size” or “Member Reference” fields. “ModuleMemberList” shall only 
be used in place of a “Member Size” and “Member Reference” field pair. When the field value 
specified in the “ProxyAssem” is “ModuleMemberList” all “Member Size” and “Member 
Reference” fields specified in the “ProxiedAssem” shall be used. It shall be legal to specify 
field values for “ProxiedAssem” entries whose corresponding field value in the 
“ProxyAssem” is not “Module”, however, these field values shall not by used, they shall exist 
only for documentation. 
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Figure 7-3.11. Example of ProxyParam and ProxyAssem 


[Params] 
Param! = 0,,,0x0010,2,2,” Target Error Codes","","",0,0xFFFF,0,0,0,0,0,0,0,0,0,0; 
ProxyParam1 = 0,,,0x0000,2,2,"input size","","",Module,Module,Module,0,0,0,0,,,,,0; 
ProxyParamSizeAdder1=4,4,4; 
[Assembly] 
Assem1 = "connection input format",,,,,, 
32,Param1, 
,ProxyAssem1, 
,ProxyAssem?2; 
ProxyAssem1 = "real time input format","20 7D 24 SLOT 30 0A",,,,, 
ModuleMemberList; 
ProxyAssem2 = "real time status format","20 7D 24 SLOT 30 0B",,,,, 
ModuleMemberList; 


[Connection Manager] 
ProxyConnect1 = 0x010100002, 0x44244401, 
2,0,, 2, ProxyParaml, Asseml1,,,, , "Listen Only", "", 
"01 SLOT_MINUS_ONE 20 04 24 03 2C 04 2C 02"; 


Figure 7-3.12. Example of ProxiedParam and ProxiedAssem 


[Params] 
ProxiedParaml =,,,,,,"input size","","",0,2,2.,,,,555955 
[Assembly] 
ProxiedAssem1 = "real time input format",,,,,; 
ProxiedAssem2 = "real time status format",,,,,,16,; 


[Connection Manager] 
ProxiedConnectl = ,,,0,,,.55555953 


Additions to the Connection Manager Section 


The “ProxyConnect” and “ProxiedConnect” keywords shall be used to describe connections 
that are proxied by a CIP adapter device to another device that does not support the CIP 
protocol. An example of this is a ControlNet adapter module (the device proxying the 
connection) in a multiple slot I/O rack with an analog I/O module (the device the connection is 
proxied for). 


The “ProxyConnect” keyword entry shall exist in the EDS for the device that performs the 
proxy. In the example above, this would be the ControlNet adapter module. 


The “ProxiedConnect” keyword entry shall exist in the EDS for the device that the proxy is 
performed for. In the example above, this would be the analog I/O module. 


The information in the [Modular] section shall be used to associate EDS files containing 


“ProxyConnect” keywords to EDS files containing “ProxiedConnect” keywords. This 
association shall exist when both EDS files specify a matching Rack entry. 
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The decimal number (that is combined with “ProxyConnect” and “ProxiedConnect’”) shall be 
used to match a “ProxyConnect” to a “ProxiedConnect”. The field values of a matched 
“ProxyConnect” and “ProxiedConnect” pair shall be combined to constitute the same field 
value information that exists in a single “Connection” entry. This combination shall be done 
by using the field values from the “ProxyConnect” except for those fields where the value is 
the keyword “Module”. In those cases, the field value specified in the associated 
“ProxiedConnect” shall be used. It shall be legal to specify field values for 
“ProxiedConnect” entries whose corresponding field value in the “ProxyConnect” entry is 
not “Module”, however, these field values shall not be used, they shall exist only for 
documentation. The field value for the “ProxyConnect” “connection name string” field shall 
not be “Module”, the “ProxyConnect” shall always specify the “connection name string”. 
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INTRODUCTION 


The CIP application layer can be used on a variety of network technologies. Each CIP network 
specification consists of two volumes. This volume is not currently specifying any common 
physical layer behavior. See Volume 2 (of the appropriate CIP network adaptation) for 
physical layer behavior defined on that network. 


Examples of CIP Networks include: DeviceNet, ControlNet, and EtherNet/IP. 
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INTRODUCTION 


The CIP application layer can be used on a variety of network technologies. Each CIP network 
specification consists of two volumes. This volume is not currently specifying any common 
indicator or middle layer behavior. See Volume 2 (of the appropriate CIP network adaptation) 
for indicator or middle layer behavior defined on that network. 


Examples of CIP Networks include: DeviceNet, ControlNet, and EtherNet/IP. 
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10-1 INTRODUCTION 


The communication objects within Chapter 3, in particular services of the Connection 
Manager, provide bridging and routing between CIP subnets. This chapter will describe how 
bridging and routing is accomplished using those objects. 


10-2 CIP ROUTING 


The Forward Open, Forward Close, and Unconnected Send services of the Connection 
Manager object allow for routing of messages and for the establishment of connections across 
bridges. Use of the Port Segment within the Connection Path parameter of the above services 
provides the routing information. The Port Segment encoding is described in Appendix C. 
Routing is ‘fixed path’ (data will always follow the same path); this is critical for insuring 
consistant I/O transaction times. 


Each Port Segment represents a ‘hop’ in the path, from one subnet to another, and the CIP 
router removes it’s Port Segment from the path before forwarding the service to the next 
destination. The Port Segment tells the router which port (subnet) to send the message on and 
the node address of the destination node on that subnet. The final target receives a Connection 
Path with no Port Segments remaining. 


A connection originator can use the Port Object within each CIP router to determine the types 
of subnets which can be reached (routed to) through that device. The Port Object, described in 
Chapter 3, provides the port name, port number within the device, and other port information 
for each routable port on the device. 


10-3 OBJECT ADDRESSING SPACE 


A CIP router may actually be the Target Device in an Unconnected Send Request. One use for 
this would be to access link specific objects within the address space of port which is not the 
port the request entered on. Link type objects (such as the ControlNet Object, DeviceNet 
Object, Connection Manager Object or Connection Object) within a device may (and in some 
cases are required to) have the same instance numbers on each port. 


For example, considering a device containing multiple DeviceNet ports, requesting an attribute 
within instance one of the DeviceNet Object on a port will always return the value associated 
with the DeviceNet object on that port. Since the DeviceNet object associated with a different 
port is also addressed as instance one, it is necessary to ‘route’ to that object. The following 
diagram shows a possible internal object layout for a router. Note that in this example Port 
Object instance | is Port number 2 and Port Object instance 2 is Port number 3. 
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Figure 10-3.1. Object Address Space within a CIP Node 
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In this example, a request to Instance 1 of the DeviceNet Object entering on Port 2 (Node 
Address 3) will be serviced by the DeviceNet Object in Port 2’s object space. In order to 
access Instance 1 of the DeviceNet Object in Port 3’s object space, the Unconnected Send 
service of the Connection Manager Object for Port 2 needs to be used. The Route Path 
parameter within the Unconnected Send service would contain 03 07 indicating that the request 
should be routed to Port 3 within the device, Node 7 on that network. The router must detect 
that it is Node 7 on the network with which Port 3 is connected, process the request 
accordingly, and send a response. 


CIP ROUTING BEHAVIOR 


The table below presents the Events that an Offlink Connection Manager Object instance 
experiences and the appropriate actions to take. 
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Table 10-4.1. CIP Routing Event/Action Matrix 


Event Action To 
Description Take’ 


Connection Manager Object Instance receives a 
valid Unconnected Send Request that DOES 
NOT need to be forwarded on through more 
intermediate hops. 


Connection Manager Object Instance receives 
an invalidly formatted Unconnected Send 
Request. 


Failure to execute the Explicit Messaging 
transaction with the Remote Target Device. 
This is due to: 


e Failure to establish an Explicit Messaging 
Connection 


Open Explicit Messaging Connection 
Error Response 


Timeout waiting for the Explicit 
Messaging Response. 


Failure to execute the Unconnected Send 
transaction with the next CIP Router in the 
path. This is due to: 


e Failure to establish an Explicit Messaging 
Connection 


Open Explicit Messaging Connection 
Error Response 


Timeout waiting for the Unconnected 
Send Explicit Messaging Response. 


Unconnected Send Request is received but it 
cannot be processed due to an internal resource 
error (e.g. queue overflow, no buffers available, 
etc.). 


Connection Manager Object Instance receives a 
valid Unconnected Send Request that needs to 
be routed through more intermediate hops 
before it reaches its final destination network. 


Explicit Messaging Response OR an 
Unconnected Send Response is received by a 
CIP Router. 
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Process and update the timing parameters’. Internally route the 
request to the specified port’s protocol engine. Establish an 
Explicit Messaging Connection with the Remote Target Device. 
Extract the Explicit Messaging Request parameters from the 
Message Request portion of the Unconnected Send Service Data. 
Deliver the Explicit Messaging Request to the Remote Target 
Device. Start a “wait for response” timer whose value is the 
number of milliseconds specified by the current (updated) timing 
parameters. 


Return a Routing Error that conveys the detected problem. See 
the Packet Validation section below for more details. 


Return a Routing Error with the following settings: 
General Status field is set to 01 


Additional Status array contains a single UINT value of 
0x0204 


remainingPathSize is set to the value zero (0). 


Return a Routing Error with the following settings: 
General Status field is set to 01 


Additional Status array contains a single UINT value of 
0x0204 


remainingPathSize is set to the number of words remaining 
in the “pre-stripped” path. 


Return a Routing Error with the following characteristics: 
General Status field is set to 02 
Additional Status array is empty 


remainingPathSize is set to the “pre-stripped” number of 
words remaining in the Route_Path field. 


Process and update the timing parameters’. Internally route the 
request to the specified port’s protocol engine. Strip off the 
appropriate portion of the routing information and update the 
Transaction_Id field if necessary. Establish an Explicit 
Messaging Connection with the next CIP Router and deliver the 
updated Unconnected Send Request accordingly. Start a “wait 
for response” timer whose value is the number of milliseconds 
specified by the current timing parameters (AFTER they have 
been updated). 


Determine whether or not the Explicit Messaging Connection 
across which the associated Unconnected Send Request is still 
active (did not experience an Inactivity/Watchdog timeout). 
Determine whether or not a timeout error has already been 
returned for this transaction. If the Explicit Messaging 
Connection is still active and a routing error has yet to be 
returned for this transaction, then formulate the appropriate 
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Event Action To 
Description Take’ 
Unconnected Send Response and return it across that Explicit 
Messaging Connection. This may entail restoring the requester’s 
Transaction_Id field on DeviceNet. If a Routing Error has 
already been returned OR the Explicit Messaging Connection is 
no longer active, then the CIP Router shall discontinue all 


processing associated with this transaction. 


CIP Router experiences a timeout while waiting | Return a Routing Error with the following settings: 

for an Explicit Messaging Response from either General Status field is set to 01 

another CIP Router (to which an Unconnected s ; ; 

Send request had been forwarded) or the Additional Status array contains a single UINT value of 
Remote Target Device (to which the actual 0x0204 

Explicit Messaging Request had been remainingPathSize is set to the number of words remaining 
delivered). in the “pre-stripped” path. 


ne Any time an Connection Manager Object receives an Unconnected Send Request it SHALL process the timing 
parameters. 


> _ Whenever an Unconnected Send Request/Response is transmitted/received, a counter within the Connection 
Manager Object Instance associated with the port across which this transmission/reception took place shall be 
incremented. 


10-5 DEVICENET MODIFICATIONS 


The services of the Connection Manager are not supported by DeviceNet nodes when it is the 
target of the request. Thus, only nodes which provide routing to/from DeviceNet support the 
Connection Manager object. When the target node of a message is on DeviceNet, these routers 
are required to translate the message into normal DeviceNet explicit messaging format. As a 
result, DeviceNet nodes require no changes to accept routed messages from other CIP subnets. 


In order to allow these routers the ability to handle multiple outstanding transactions on 
DeviceNet, the Unconnected Send service of the Connection Manager is modified when 
traversing a DeviceNet subnet. The details are provided in 10-4.1 and 10-4.2 below. 


10-5.1 Unconnected Send Service Request Modification 


When sent on a DeviceNet subnet, the Unconnected Send service data is prepended with a 16- 
bit transaction ID. This transaction identifier is generated by the requesting device and 
returned by the router along with the response from the target. The modified service request is 
as shown below. 
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Table 10-5.1. Unconnected Send Service Parameters 


Parameter Name Data Type Description 


Transaction_ID UINT Used for transaction management in the DeviceNet Requesting Device 
and DeviceNet Routers. This field is used for transaction matching by 
message originators on DeviceNet not passed on to other subnets 


Priority/Time_tick BYTE Used to calculate request timeout information. 
Time-out_ticks USINT Used to calculate request timeout information. 
Message_Request_Size UINT Specifies the number of bytes in the Message Request. 
Message Request! Struct of 
Service | USINT Service code of the request. 
Request_Path Size | USINT The number of 16 bit words in the Request_Path field (next element). 


Request_Path | Padded This is an array of bytes whose contents convey the path of the request 
EPATH (Class ID, Instance ID, etc.) for this transaction. 


Request_Data | Array of Service specific data to be delivered in the Explicit Messaging Request. 
octet If no additional data is to be sent with the Explicit Messaging Request, 
then this array will be empty. 


Pad USINT Only present if Message _Request_Size is an odd value. 
Route Path Size USINT The number of 16 bit words in the Route_Path field. 
Reserved USINT Reserved byte. Shall be set to zero (0). 


Route_Path Padded Indicates the route to the Remote Target Device. 
EPATH 


' This is the Message Router Request Format as defined in Chapter 2. 


Unconnected Send Service Response Modification 


A DeviceNet router shall always return a successful response to a Unconnected Send service 
request. This success response may actually indicate that an error was encountered. This is 
necessary because additional error information is needed to handle routing errors and this 
additional information does not conform to the Error Response format defined for DeviceNet. 
As specified in Chapter 3, the Service code returned may be either the service code sent inside 
the Unconnected Send service data or the Unconnected Send service code. The 0x94 Error 
Response Service is never returned. 


The modified successful and unsuccessful service responses are as shown below. Note that this 
is the data placed within the DeviceNet Service Data area; the reply service code is earlier in 
the packet. 


Table 10-5.2. Successful Unconnected Send Response 


Parameter Data Type Description 
Name 


Transaction ID UINT Echoes the value received in the associated Unconnected Send Request. 
General Status USINT This value is zero (0) for successful transactions. 


Reserved USINT Shall be zero. 


Service Array of | This field contains the Explicit Messaging Service Data returned by the Target 
Response Data byte Device/Object. For example, this would contain Attribute Data in response to a 
Get_Attribute_Single request. If the Explicit Messaging response returned by 


the Target Device/Object did not contain any Service Data, then this field shall 
be empty. 


The response Service Data associated with an unsuccessful Unconnected Send response is 
defined below. 
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Table 10-5.3 Unsuccessful Unconnected Send Response 


Parameter Name Data Type Description 
Transaction ID UINT Echoes the value received in the associated Unconnected Send 
~ Request. 
General Status USINT One of the General Status codes listed in Appendix B Error Codes. If 


a routing error occurred, it shall be limited to the values specified in 
the Routing Error Values table. 


Size of Additional USINT Number of 16 bit words in Additional Status array. 
Status 
Additional Status Array of UINT | When returning an error from a target which is a DeviceNet node, the 


Additional Status shall contain the 8 bit Additional Error Code from 
the target in the lower 8 bits and a zero (0) in the upper 8 bits. 
Remaining Path Size USINT This field is only present with routing type errors and indicates the 
number of words in the original route path (Route _Path parameter of 
the Unconnected Send Request) as seen by the router that detects the 
error. 


EXAMPLES 
Using the Unconnected Send Service For Explicit Messaging — Single Hop 


This section presents examples to further clarify the operation of the Connection Manager 
Object and the Unconnected Send service. 


Assume that the Requesting Device wants to execute a Get_Attribute_ Single on Class 
#1/Instance #2/Attribute ID #3 in the Target Device. 


Figure 10-6.1. Single Hop Unconnected Send (Explicit Message Request/Response) 


Get_Attribute_Sineté specifying Class #1/Instancex 


DeviceNet to EtherNet/IP Router 


Port ID =2 Port ID =3 


IP Address IP Address 
130.151.137.112 130.151.137.105 


DeviceNet EtherNet/IP 


Requesting 
Device 


MAC ID=5 


The table below presents the contents of the Service Data field for the Unconnected Send 
request which is used to execute the Get_Attribute_Single example noted above (all values are 
in hex). 
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Table 10-6.2. Single Hop Unconnected Send Request Service Data 


| pp i Priority/Tick Time field, 


Service field = Get_Attribute_Single. 


21 00 01 00 25 00 02 00 | Path field specifying 16 bit Class Id = 1, 16 bit Instance ID = 2, 8 bit Attribute Id = 3. 
Note the presence of the pad bytes immediately following the 0x21 and 0x25 bytes. 
This path could have also been formatted as follows: 20 01 24 02 30 03 which makes use 
of 8 bit values to convey the Class and Instance ID data. In the 8 bit case, the pad bytes 
are not required. 


| 09. Route Path Size field indicates that there are 9 words in the route path. 
| 00S Reserved byte. 


13 OF 31 33 30 2E 31 Contents of the Route_Path field. This field specifies the routing information. These 

35 31 2E 31 33372E bytes indicate that the request is to be delivered out Port #3 and to IP Address 

31 30 35 00 130.151.137.105. This path encoding uses the Extended Link Address format for the IP 
address. 


Step 1 — Request delivered to the DeviceNet to EtherNet/IP Router 


The first step in the process calls for the Requesting Device to establish an Explicit Messaging 
Connection with the DeviceNet to EtherNet/IP Router and issue the Unconnected Send request. 
The table below presents the entire Unconnected Send request. Assume that the Message Body 
Format established for the Explicit Messaging Connection is DeviceNet 8/8. 


Table 10-6.3 Explicit Message Request on DeviceNet 


P06 | Class ID of the Connection Manager ObjectClass; 
01 00 pp tt OC 00 OE 05 Unconnected Send Service Request Data. This is the previously described 
21 00 01 00 25 00 02 00 Unconnected Send service data describe above with the Transaction_Id field as the 
30 03 09 00 13 OF 31 33 first UINT value (01 00 for this example). 


30 2E 31 35 31 2E 31 33 
37 2E 31 3035 00 


'_ This request would have to be fragmented to deliver it to the router. Fragmentation is not illustrated 
in this example. 


The Unconnected Send request has now been delivered to the DeviceNet to EtherNet/IP Router 
via an Explicit Messaging Connection that exists between the Requesting Device and the 
DeviceNet to EtherNet/IP Router. 
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Step 2 — Router delivers the request to the Target Device 


When the Connection Manager Object within the DeviceNet Router receives the Unconnected 
Send request it examines the contents of the Route_Path field. In this case, the contents are “13 
OF 31 33 30 2E 31 35 31 2E 31 33 37 2E 31 3035 00”. This indicates that the next device in 
the hop is on Port #3 and its Node (IP) Address is 130.151.137.105. Additionally, since there 
is only a single Port/Node Address pair specified in the Route_Path, the request has reached its 
destination network. When a DeviceNet Router receives an Unconnected Send Request that 
DOES NOT need to be forwarded through more intermediate CIP Routers, the following steps 
are taken: 


e The DeviceNet Router executes the timing related logic associated with the Priority/Tick 
Time and Connection Timeout Ticks fields. If a timeout is detected, then a successful 
Unconnected Send response that specifies a Routing Error is returned to the Requesting 
Device. 

e The DeviceNet Router extracts the actual transaction from the Message Request portion of 
the Service Data and delivers the Explicit Messaging Request to the Target Device. The 
actual method of delivering the explicit message is dependant on the link type. 


In this example, the message request inside the Unconnected Send indicates a 

Get Attribute Single to Class #1, Instance #2, Attribute #3. This approach has no effect on the 
Target Device. The Target Device does not even realize it has just responded to a request that 
originated on a remote DeviceNet. 


Step 3 — Target returns the Explicit Message response to the Router 


The Target Device processes the explicit message and returns a response to the Router. When 
the Get_Attribute_Single Response is received by the DeviceNet Router it generates the 
Unconnected Send Response and internally delivers it to the Explicit Messaging Connection 
across which the Unconnected Send Request was originally received. 


Step 4 — Router returns the Unconnected Response to the Requesting Device 


The DeviceNet Router then delivers the Unconnected Send Response to the original 
Requesting Device. 


Assume that the Target Device returns a successful response to the Get Attribute Single and 
the requested attribute is a UINT whose value is 0x1234. The text below presents the contents 
of the CAN Data Field associated with the Unconnected Send Response returned to the 
Requesting Device: 
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Table 10-6.4 Successful Explicit Message Response on DeviceNet 


The General Status field. The value zero (0) indicates that there were no routing errors 
The Success status has no additional status. 


The Target Device’s Explicit Messaging Response Service Data field. In this case, the value 
0x1234 was returned in the Get_Attribute Single response. 


Now assume that the Target Device returned an Error Response whose General Error Code was 
set to the value “2” and whose Additional Error Code field was set to the value “5”. The text 
below presents the contents of the CAN Data Field associated with the Unconnected Send 
Response returned to the Requesting Device. The absense of the Remaining Path Size field 
inidcates that this error (Error Code = 2) was returned from the Target Device, not an 
intermediate router. 


Table 10-6.5 Unsuccessful Explicit Message Response on DeviceNet 


Frag = 0, Transaction ID = 0, Destination MAC = 5. 


The Size of Additional Status field. This indicates that the Target Device returned 16 bits of 
additional status 


This indicates that the Target Device returned an Additional Error Code of 0x05. 


Finally, assume that the DeviceNet Router was unable to establish an Explicit Messaging 
Connection with the Target Device. In this case a Routing Error has occurred (the request was 
not delivered to the Target Device). The error code and extended status that most closely 
conveys the routing error is: General Code = 0x01, Extended Code = 0x0204 — Unconnected 
Send timed out waiting for a response (Note that error handling is dealt with in more detail in 
the Event/Action Matrix in 10-4). The text below presents the contents of the CAN Data Field 
associated with the Unconnected Send Response returned to the Requesting Device: 


Service = 0x8E. In this context, this specifies a response to the Unconnected Send service. 


Table 10-6.6 Routing Failure Explicit Message Response on DeviceNet 


The Size of Additional Status field. This indicates that there is 16 bits of additional status. 


04 02 The Additional Status field. There is a single UINT whose value is 0x0204. 
The Remaining PathSize field. The value zero (0) indicates that an error was encountered 
during the attempt to establish communications with the Remote Target Device versus another 


DeviceNet Router. 
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Using the Unconnected Send Service For Explicit Messaging — Multiple Hop 


Assume that the Requesting Device wants to execute a Set Attribute Single on Class 
#1/Instance #2/Attribute ID #3 in the Target Device. Assume that the data being sent to this 
attribute is a byte array whose value is 01 02 03 ... 09. Notice that this transaction will flow 
through two DeviceNet Routers. 


Figure 10-6.7. Multiple Hop Unconnected Send 


Set_Attribute Single specifyjag Class #1/Instance #2/Attribute #3, A 


ibute Value = 01 02 03 ... 09 


DeviceNet to DeviceNet DeviceNet to DeviceNet 


Router #1 Router #2 
Target Device 
PortID=3 Port ID=2 PorttID=3 PortID=4 


MAC ID=7 MAC ID=9 MAC ID =4 MAC ID=6 


Requesting 
Device 


MAC ID=5 


DeviceNet #1 DeviceNet #2 DeviceNet #3 


Step 1 — Request delivered to DeviceNet to DeviceNet Router #1 


The first step in the process calls for the Requesting Device to establish an Explicit Messaging 
Connection with DeviceNet to DeviceNet Router #1 and issue the Unconnected Send request. 
This is identical to Step #1 in the previous example. The text below presents the contents of the 
Unconnected Send request’s Service Data field which is used to execute the 
Set_Attribute_Single noted above (all values are in hex). 


Table 10-6.8. Multiple Hop Unconnected Send Request Service Data (First Hop) 


Message_Size field = 17 bytes. Note that this means that a pad byte will be 
inserted between the Request_Data field and the Route Path Size field. 
10 Service field = Set_Attribute_Single. 


03 Request_Path Size field indicates that there are 3 words in the request path 


20 01 24 02 30 03 Request_Path field specifying 8 bit Class Id = 1, 8 bit Instance ID = 2, 8 bit 
Attribute Id = 3. 

01 02 03 04 05 06 07 08 Request_Data field specifying the attribute data associated with the 

09 Set_Attribute Single request. 


Pad byte (required due to the odd length) 


Route_Size field indicates that there are 2 words in the Route _Path 
0 Reserved byte 


02 09 04 06 Contents of the Route_Path field specifying the routing information. These bytes 
indicate that the request is to be delivered out Port #2 and to MAC ID 9 and then 
out Port #4 to the Target Device at MAC ID 6. 
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Step 2 — Request delivered to DeviceNet to DeviceNet Router #2 


When DeviceNet Router #1 receives the Unconnected Send request with this Service Data field 
it detects that there are more intermediate devices to go through before the Target Device can 
be reached. In this case, DeviceNet Router #1 executes the following steps: 


e Executes the timing related logic associated with the Priority/Tick Time and Connection 
Timeout Ticks fields. If a timeout is detected, then a successful Unconnected Send 
response, which specifies a Routing Error, is returned to the Requesting Device. 

e Strips its portion of the routing information from the Unconnected Send request’s 
Route_Path field and forwards the Unconnected Send Request accordingly. In this 
example, the “02 09” bytes constitute the routing information pertinent to DeviceNet 
Router #1 (next hop indicator). These bytes indicate that the Unconnected Send Request 
should be sent out Port #2 and to MAC ID #9 on that subnet. 

e Establishes an Explicit Messaging Connection with DeviceNet Router #2 (if necessary) and 
sends the remaining data in the Unconnected Send service the second router. 


The Service Data field of the Unconnected Send Request that DeviceNet Router #1 forwards to 
DeviceNet Router #2 is presented below. In this example, DeviceNet Router #1 is making use 
of the Transaction_Id field for internal transaction management purposes and that the value “1” 
which was received with the request is already in use. In this case the DeviceNet Router #1 is 
free to allocate an unused value (assume the value “4’) and insert it into the packet it forwards. 


Table 10-6.9. Multiple Hop Unconnected Send Request Service Data (Second Hop) 


The Transaction_Id field inserted by the router. 
Priority/Tick Time field (Time Tick = 128 ms). 


Connection Timeout Ticks field (8 Ticks which results in 1024 ms timeout, 512 ms 


Request_Path Size field indicates that there are 3 words in the request path. 
Request_Path field specifying 8 bit Class Id = 1, 8 bit Instance ID = 2, 8 bit 
Attribute Id = 3. 


01 02 03 04 05 06 07 08 Request_Data field specifying the attribute data associated with the 
09 Set_Attribute Single request 
Pad byte. 


Ol 
Route_Path indicating that the request is to be delivered out Port #4 to the Target 
Device at MAC ID 6. Note that DeviceNet Router #1 has stripped its routing 
information from the packet. 


Step 3 — Request delivered to Remote Target Device 


When DeviceNet Router #2 receives this Service Data field in the Unconnected Send Request 
it behaves identical to the DeviceNet Router in the first example. Specifically, DeviceNet 
Router #2 executes the following steps: 


e Executes the timing related logic associated with the Priority/Tick Time and Connection 
Timeout Ticks fields. If a timeout is detected, then a successful Unconnected Send 
response that specifies a Routing Error is returned to the Requesting Device. 
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e Since there is no additional path routing, the device at MAC ID 6 is the Remote Target 
Device. The DeviceNet Router establishes an Explicit Messaging Connection with that 
device (if necessary), extracts the actual transaction from the Message Request portion of 
the Service Data, and delivers the Explicit Messaging Request to the Target Device. 


The response returns back to the Requesting Device with each DeviceNet Router utilizing the 
Transaction_Id field to facilitate internal transaction management. If an error was detected at 
any point in the process, then the appropriate error information would be returned in the 
successful Unconnected Send Response. 


Using the Forward Open Service to Open an I/O Messaging Connection 


Assume that the Requesting Device wants to make an I/O conneciton to an I/O Assembly. This 
data for this Assembly is identified as Class #4/Instance #2/Attribute ID #3 in the Target 
Device. 


Figure 10-6.10. Forward Open to Establish I/O Connection 


Forward Open to Class #4/Instance #2/A: 


DeviceNet to EtherNet/IP Router 


Port ID =2 Port ID =3 


IP Address IP Address 
130.151.137.112 130.151.137.105 


DeviceNet EtherNet/IP 


Requesting 
Device 


MAC ID=5 


The table below presents the contents of the Service Data field for the Forward Open request 


which is used to execute the connection establishment example noted above (all values are in 
hex). 


Table 10-6.11. Forward Open Request Service Data 


Byte Value Meaning 


| spp —_| Priority/Tick Time field. 
Connection Timeout Ticks field. 

45 00 00 00 O_to_T Connection ID — Chosen by originating node (CAN ID 0x045 = Node 5, Group 1, 
ee 
T_to_O Connection ID — Chosen by target node 
Connection Serial Number 
Originator Vendor ID (Vendor ID = 65535) 
Originator Serial Number (Serial Number = 0x03020100) 

Connection Timeout Multiplier 


00 00 00 Reserved 
20 Al 07 00 O_to_T RPI (0x7A120 = 500 ms) 


D> = -as =. Il O_to_T Connection Parameters 
20 Al 07 00 T_to_O RPI (0x7A120 = 500 ms) 


T_to O Connection Parameters 


t 
Transport Type / Trigger (Class 2 Cyclic Server) 


Connection Path Size field indicates that there are 14 words in the connection path. 
13 OF 31 33 30 Contents of the Connection Path field. This field specifies the routing/connection 
°F 3135 312E information. These bytes indicate that the request is to be delivered out Port #3 and to IP 
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Byte Value 


31 33 37 2E31 Address 130.151.137.105. This path encoding uses the Extended Link Address format for 


3035 2100 04 the IP address. It further indicates that the application being connected to by specifying 16 
00 25 00 02 00 30 | bit Class ID = 4, 16 bit Instance ID = 2, 8 bit Attribute ID = 3. 
03 00 


Step 1 — Request delivered to the DeviceNet to EtherNet/IP Router 


The first step in the process calls for the Requesting Device to establish an Explicit Messaging 
Connection with the DeviceNet to EtherNet/IP Router and issue the Forward Open request. The 
table below presents the entire Forward Open request. Assume that the Message Body Format 
established for the Explicit Messaging Connection is DeviceNet 8/8. 


Table 10-6.12. Forward Open Request on DeviceNet 


Frag = 0, Transaction ID = 0, Destination MACID =7. 
| 06 | Class 1D of the Connection Manager ObjectClass5 


01 00 pp tt OC 00 OE 05 21 00 | Forward Open Service Request Data. This is the previously described 
04 00 25 00 02 00 30 03 09 00 | Forward Open service data described above. 

13 OF 31 33 30 2E 31 35 31 

2E 31 33 37 2E 31 3035 00 

"_ This request would have to be fragmented on DeviceNet to deliver it to the router. DeviceNet 
fragmentation is not illustrated in this example. 


The Forward Open request has now been delivered to the DeviceNet Router via an Explicit 
Messaging Connection that exists between the Originating Device and the DeviceNet Router. 


Step 2 — Router creates a CIP Bridged connection 


Upon receipt of a Forward Open to the Connection Manager object, the router shall (if it has 
the resources available) create a CIP Bridged connection (Class Code 0x05) and place it in the 
Configuring state. The remaining attributes are set with either the values received in the 
service request or the appropriate default values. If resources are unavailable, an error response 
is returned. 


Step 3 — Router creates connection with the Target Device 


After the Connection Manager Object within the DeviceNet Router processes the Forward 
Open request it examines the contents of the Connection Path field. In this case, the contents 
are “13 OF 31 33 30 2E 31 35 31 2E 31 33 37 2E 31 30 35 21 00 04 00 25 00 02 00 30 03 00”. 
This indicates that the next device in the hop is on Port #3 and its Node (IP) Address is 
130.151.137.105. Additionally, since there is only a single Port/Node Address pair specified in 
the Connection_Path field, the request has reached its destination network. When a DeviceNet 
Router receives an Forward Open Request that DOES NOT need to be forwarded through more 
intermediate CIP Routers, the following steps are taken: 


e The DeviceNet Router executes the timing related logic associated with the Priority/Tick 
Time and Connection Timeout Ticks fields. If a timeout is detected, then a successful 
Forward Open response that specifies a Routing Error is returned to the Requesting Device. 
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e The DeviceNet Router creates an I/O connection with the Target Device. Once the I/O 
connection is created, the connection attributes are set, and the connection is applied. 
(Note that if the connection path indicates the Message Router object, then the router opens 
an Explicit Messaging connection using the UCMM.) 


In the example above, the connection path inside the Forward Open indicates an I/O connection 
to Class #4, Instance #2, Attribute #3. 


Step 4 — Router returns the Forward Open Response to the Requesting Device 


The DeviceNet Router then delivers the Forward Open Response to the original Requesting 
Device. This response will contain the actual packet rates and the connection identifiers to be 
used. 


The service data field for a Forward Open response is shown below. 


Table 10-6.13. Forward Open Response Service Data 


45 00 00 00 O_to_T Connection ID — Chosen by originating node (CAN ID 0x045 = Node 5, Group 1, 
Msg ID 1) 


07 01 00 00 T_to_O Connection ID — Chosen by target node (CAN ID 0x107 = Node 7, Group 1, Msg 
ID 4) 


F_00 | Connection Timeout Multiplier SSCS 
| 00. ~——_| Application reply size (no application reply data) 
ae a 


Reserved 


Assume that the connection to the Target Device was successful. The text below presents the 
contents of the CAN Data Field associated with the Forward Open Response returned to the 
Requesting Device: 


Table 10-6.14. Forward Open Response on DeviceNet 


| 00 | The General Status field. The value zero (0) indicates that there were no routing errors. | 
| 00s Reservedbyte, 


45 00 00 00 07 01 Forward Open Service Response Data. This is the previously described Forward Open 
00 00 OC 00 FF FF | service data described above. 

00 01 02 03 00 00 

00 00 20 Al 07 00 

20 Al 07 00 00 00 


Using the Forward Close Service to Close an I/O Messaging Connection 


The table below presents the contents of the Service Data field for the Forward Close request to 
delete the connection which was established in the example above (all values are in hex). 
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Table 10-6.15. Forward Close Request Service Data 


| pp | Priority/Tick Time field 


P00 Reserved 


13 OF 31 33 302E | Contents of the Connection_Path field. This field specifies the routing/connection 

3135 31 2E 31 33 information. These bytes indicate that the request is to be delivered out Port #3 and to IP 

37 2E 313035 21 | Address 130.151.137.105. This path encoding uses the Extended Link Address format for the 
00 04.00 2500 02._‘| IP address. It further indicates the application being disconnected from by specifying 16 bit 
00 30 03 00 Class ID = 4, 16 bit Instance ID = 2, 8 bit Attribute ID = 3. 


Step 1 — Request delivered to the DeviceNet to EtherNet/IP Router 


The first step in the process calls for the Requesting Device to establish an Explicit Messaging 
Connection with the DeviceNet to EtherNet/IP Router (if one does not exist) and issue the 
Forward Close request. The table below presents the entire Forward Open request. Assume 
that the Message Body Format established for the Explicit Messaging Connection is DeviceNet 
8/8. 


Table 10-6.16. Forward Close Request on DeviceNet 


Frag = 0', Transaction ID = 0, Destination MACID = 7. 

Service = 5E. In this context, this specifies the Forward Close service. 
a eee Class ID of the Connection Manager Object Class. 

The Instance ID Field specifying instance | of the Connection Manager. 


01 00 pp tt OC 00 OE 05 21 00 04 | Forward Close Service Request Data. This is the previously described 
00 25 00 02 00 30 03 09 00 13 OF | Forward Close service data described above. 

31 33 30 2E 31 35 31 2E 31 33 

37 2E 31 3035 00 

"_ This request would have to be fragmented to deliver it to the router. DeviceNet fragmentation is 
not illustrated in this example. 


The Forward Close request has now been delivered to the DeviceNet Router via an Explicit 
Messaging Connection that exists between the Originating Device and the DeviceNet Router. 


Step 2 — Router deletes the CIP Bridged connection with Target 


After the Connection Manager Object within the DeviceNet Router processes the Forward 
Close request it examines the contents of the Connection_Path field. In this case, the contents 
are “13 OF 31 33 30 2E 31 35 31 2E 31 33 37 2E 31 30 35 21 00 04 00 25 00 02 00 30 03 00”. 
This indicates that the next device in the hop is on Port #3 and its Node (IP) Address is 
130.151.137.105. Additionally, since there is only a single Port/Node Address pair specified in 
the Connection_Path, the request has reached its destination network. When a DeviceNet 
Router receives an Forward Close Request that DOES NOT need to be forwarded through 
more intermediate CIP Routers, the following steps are taken: 
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The DeviceNet Router executes the timing related logic associated with the Priority/Tick Time 
and Connection Timeout Ticks fields. If a timeout is detected, then a successful Forward Close 
response that specifies a Routing Error is returned to the Requesting Device. 


The DeviceNet Router deletes the I/O or Explicit Messaging connection with the Target 
Device. 


Step 3 — Router returns the Forward Close Response to the Requesting Device and 
releases internal resources 


The DeviceNet Router then delivers the Forward Close Response to the original Requesting 
Device and releases all internal resources related to the connections on both the DeviceNet and 
EtherNet/IP subnets. 


The service data field for a Forward Close response is shown below. 


Table 10-6.17. Forward Close Response Service Data 


Byte Value 
0C 00 Connection Serial Number 
FF FF Originator Vendor ID (Vendor ID = 65535) 


00 01 02 03 Originator Serial Number (Serial Number = 0x03020100) 
| -—-00-~——__| Application reply size (no application reply data) 


Reserved 


Assume that the connection to the Target Device was successful. The text below presents the 
contents of the CAN Data Field associated with the Forward Close Response returned to the 
Requesting Device: 


Table 10-6.18. Forward Close Response on DeviceNet 


Frag = 0, Transaction ID = 0, Destination MAC =7. 
Service = DE. In this context, this specifies a response to the Forward Close service. 


The General Status field. The value zero (0) indicates that there were no routing errors. 


| 00 Reserved byte. 


OC 00 FF FF 00 01 | Forward Close Service Response Data. This is the previously described Forward Close 
02 03 00 00 service data described above. 
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A-1 INTRODUCTION 


This appendix contains information about Explicit Messaging services. The CIP Common 
Services are defined and examples illustrating the encoding of CIP Common Services are 
provided. CIP Common Services are those services whose request/response parameters and 
required behaviors are defined in this document. 


A-2 SERVICE DEFINITIONS 


For any CIP service to be considered “fully defined,” its definition must include the following 
information: 


e A brief functional definition explaining what the service does (why an object would 
request the service) 

e Behaviors associated with the service 

e Parameters which are placed in the Service Data Field of an Explicit Request Message, 
including: 
- Data type 
- Description 

e Parameters which are placed in the Service Data Field of an Explicit Response Message, 
including: 
- Data type 
- Description 


A-3 CIP COMMON SERVICES 


The codes and names of the CIP Common Services are listed below. 


Table A-3.1. CIP Service Codes and Names 


Service Code Service Name 
(in hex) 

00 Reserved for future use 

01 Get_Attributes_All 

02 Set_Attributes_All Request 

03 Get_Attribute_List 

04 Set_Attribute_List 

05 Reset 

06 Start 

07 Stop 

08 Create 

09 Delete 

0A Multiple Service Packet 
0B-0C Reserved for future use 

0D Apply_Attributes 

OE Get_Attribute_Single 

OF Reserved for future use 

10 Set_Attribute_Single 

11 Find_Next_Object_Instance 
12-13 Reserved for future use 

14 Error Response (used by DeviceNet only) 
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Service Code Service Name 
(in hex) 
15 Restore 
16 Save 
17 No Operation (NOP) 
18 Get Member 
19 Set Member 
1A Insert Member 
1B Remove Member 
1C-31 Reserved for additional Common Services 


A-4 CIP COMMON SERVICE DEFINITIONS 


This section provides a general description of the CIP Common Services. Objects 
Classes/Instances that utilize these Services must provide a detailed description of their specific 
use. 


A-4 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Appendix A: Explicit Messaging Services 


Get_Attribute_All 


Service Code: 01 hex 


Release 1.0 


Returns the contents of all attributes of an object or class. 


Service Requirements 


The following list details requirements associated with the 
Get_Attributes_All service: 


1. The structure of the information in the successful response’s 
Service Data Field adheres to the Get_Attributes_ All response 
structure defined by the object or class. Support of this service 
requires the Object and/or Class to provide a detailed definition 
of the format of the data sent in the response message. 


2. Ifthe request is successfully serviced, then a Get_Attributes_All 
Response is returned. The Service Data Field of the response 
contains the attribute data. If an error is detected, then an Error 
Response is returned 


Refer to Chapter 4 within of the CIP Common Specification for a 
more detailed discussion of this service. 
Request Service Data Field Parameters 


NONE 


Success Response Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a successful response to a Get_Attributes_All request 


Table A-4.1. Service Data for Set_Attributes_All Success Response 


Name Data Type Description of Parameter 


Attribute Data | Object/class A stream of information containing all of the 
attribute— attributes. Classes/Objects which support this 
specific Struct | service must define the format of this 

parameter. 
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Set_Attributes_All 


Service Code: 02hex 


A-6 


Modifies the contents of the attributes of the class or object. 


Service Requirements 


The following list details requirements associated with the 
Set_Attributes_All service: 


1. The structure of the information in the request’s Service Data 
Field adheres to the definition of the Set_Attributes All request 
for the object or class. Support of this service requires the Object 
and/or Class to provide a detailed definition of the format of the 
data sent in the request message. 


2. Ifthe ability to modify an attribute changes based on the state of 
the object, the object definition must provide a detailed 
description of how this service is effected. For example; this 
service could only be supported in a state where all attributes are 
modifiable. Alternatively, the object could ignore the data 
associated with a currently non-modifiable attribute. 


3. Attributes will be modified only if all attribute specific value 
verifications (e.g. range checks, etc.) are successful. The first 
attribute failing verification will be specified in the Additional 
Code parameter of the Error Response message. 


4. Ifany other error is detected, then an Error Response is returned. 


5. Ifall verification checks pass, then the attributes are modified and 
a Set Attributes All success response is returned. 


Refer to Chapter 4 within the CIP Common Specificationfor a more 
detailed discussion of this service. 


Request Service Data Field Parameters 
The following information is specified within the Service Data Field 
of a Set Attributes All request. 


Table A-4.2. Service Data for Set_Attributes_All Request 


Name Data Type Description of Parameter 
Attribute Data | Object/class A stream of information containing all of the 


attribute— attributes. Classes/Objects which support this 
specific Struct | service must define the format of this parameter. 


Success Response Service Data Field Parameters 


NONE 
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Get_Attribute_List The Get_Attribute_List service shall return the contents of the 
selected gettable attributes of the specified object class or instance. 


Service Code: 03 hex 
Service Requirements 


The following list details requirements associated with the 
Get_Attribute_List service: 


1. The attributes shall be specified using a list of attribute 
identifiers. 


2. The number of attributes actually returned shall be reported 
within the response. If there is not enough space for an 
attribute’s data in the response message, a partial response shall 
be returned. 


3. Attribute data returned within partial response messages shall be 
complete. The client application can submit another 
Get Attribute List service request for the attribute data 
remaining from its original list. 


4. The client application shall verify the value of the attribute count 
parameter in the response. 


5. Status shall be reported with each individual attribute. Attribute 
data shall be retrieved and packed in the sequence specified in the 
request. 


6. When “Attribute Status” is a value other than “Success” (0x00), 
the “Attribute Data” shall not be returned. 
Request Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a Get_Attribute List request. 


Table A-4.3. Service Data for Get_Attribute_List Request 


Name Data Type Description of Parameter 
Attribute_count | UINT Number of attribute identifiers in the attribute 
list 
Attribute_list ARRAY of List of the attribute identifiers to get from the 
UINT class or object 
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Success Response Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a successful Get_Attribute_Single response. 


Table A-4.4. Service Data for Get_Attribute_List Success Response 


Name Data Type Description of Parameter 
Attribute_count | UINT Number of “Attribute response structures” 
returned 
Attribute response | LIST of A list of response structures 
structures STRUCT: 

UINT “Attribute identifier’, the number of the 
attribute identifier being returned 

UINT “Attribute Status”, the status of the attribute 
response (per appendix H) 

Object/Class “Attribute Data”, Attribute response data - 


specific attribute | exists when “Attribute Status” is the value 
data “Success” (0x00). 
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Set_Attribute_List The Set_Attribute List service shall set the contents of selected 
attributes of the specified object class or instance. 


Service Code: 04hex 
Service Requirements 


The following list details requirements associated with the 
Set_Attribute List service: 


1. The data for each individual attribute shall be placed into the 
request in its entirety. 


2. Each set activity shall be performed in the order specified in the 
list. 


3. Status shall be reported for each of the individual attributes in the 
response. 


4. A server shall not attempt to set an attribute for which it can not 
return a response status. 


Request Service Data Field Parameters 


The service data field of the Set_Attribute_List request shall be as 
specified in the following table. 


Table A-4.4. Service Data for Set_Attribute_List Request 
Name Data Type Description of Parameter 


attribute_count |UINT Number of attribute identifiers in the attribute 
list 
attributes request | LIST of List of structures specific to this service 
structures STRUCT: 

UINT “Attribute Identifier” - Attribute identification 
number 

Object / class Related attribute data 

specific data 
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Success Response Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a successful Set Attribute List response. 


Table A-4.5. Service Data for Set_Attribute_List Response 


Name Data Type Description of Parameter 
attribute_count Number of attribute values being returned 


Attribute response | LIST of A list of response structures 
structures STRUCT: 
UINT “Attribute identifier’, the number of the 
attribute identifier being returned 
UINT “Attribute Status”, the status of the attribute 
response (per appendix H) 
Object/Class “Attribute Data”, Attribute response data - may 


specific attribute | exist when “Attribute Status” is the value 
data “Success” (0x00). 
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Reset 


Service Code: O5hex 


Release 1.0 


Invokes the Reset service of the specified Class/Object. Typically 
this would cause a transition to a default state or mode. 


Service Requirements 


The following list details requirements associated with the Reset 
service: 


1. Ifthe execution of the Reset service request would place the 
object/device in a state that will enable it to respond to the 
requester, then the response is not returned until the service has 
completed. If the execution of the Reset service would place the 
object/device in a state in which it may not be able to respond, 
the object/device must respond prior to executing the Reset 
service. 


2. Ifan error is detected, then an Error Response is returned. 
Otherwise, a successful Reset response is returned. 
Request Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a Reset request. 


Table A-4.6. Service Data for Reset Request 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 
Data STRUCT Class/Instance definition must specify its 


format. 


Success Response Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a successful response to a Reset request 


Table A-4.7. Service Data for Reset Success Response 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 
Data STRUCT Class/Instance definition must specify its format. 
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Start 


Service Code: 06nhex 


Invokes the Start service of the specified Class/Object. Typically this 
would place an object into a running state/mode. 
Service Requirements 


The following list details requirements associated with the Start 
service: 


1. Other than documenting the state machine associated with the 
objet/class relative to this service, there are no special 
requirements defined by CIP. 


2. Ifan error is detected, then an Error Response is returned. 
Otherwise, a successful Start response is returned. 
Request Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a Start request. 


Table A-4.8. Service Data for Start Request 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 
Data STRUCT Class/Instance definition must specify its 


format. 


Success Response Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a successful response to a Start request 


Table A-4.9. Service Data for Start Success Response 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 
Data STRUCT Class/Instance definition must specify its format. 
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Stop 


Service Code: 07 hex 


Release 1.0 


Invokes the Stop service of the specified Class/Object. Typically this 
would place an object into a stopped or idle state/mode. 
Service Requirements 


The following list details requirements associated with the Stop 
service: 


1. Other than documenting the state machine associated with the 
objet/class relative to this service, there are no special 
requirements defined by CIP. 


2. Ifan error is detected, then an Error Response is returned. 
Otherwise, a successful Stop response is returned. 
Request Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a Stop request. 


Table A-4.10. Service Data for Stop Request 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 
Data STRUCT Class/Instance definition must specify its format. 


Success Response Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a successful response to a Stop request 


Table A-4.11. Service Data for Stop Success Response 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 
Data STRUCT Class/Instance definition must specify its format. 
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Create 


Service Code: 08hex 


Results in the instantiation of a new object within the specified class. 


Service Requirements 


The following list details requirements associated with the Create 
service: 


1. The object instance is created and initialized in accordance with 
the object definition. 


2. Any error will result in the object instance not being created. 
3. Ifan error is detected, then an Error Response is returned. 

Otherwise, a successful Create response is returned. 
Request Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a Create request. 


Table A-4.12. Service Data for Create Request 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 
Data STRUCT Class/Instance definition must specify its 


format. 


Success Response Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a successful response to a Create request 


Table A-4.13. Service Data for Create Success Response 


Name Data Type Description of Parameter 


Instance ID UINT The integer value assigned to identify the 
newly created object. This is specified 
within a 16 bit field regardless of the 
Message Body Format associated with the 
Explicit Messaging Connection. 


Object Object/class Contains Class/Instance specific parameters. 
Specific Data | service— specific |If a Class/Instance utilizes this field, then 
STRUCT the Class/Instance definition must specify 
its format. 
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Delete 


Service Code: 09h.x 


Release 1.0 


Deletes an object instance of the specified class. 


Service Requirements 


The following list details requirements associated with the Delete 
service: 


1. All resources are deallocated and returned to the system. 
2. Ifan error is detected, then an Error Response is returned. 

Otherwise, a successful Delete response is returned. 
Request Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a Delete request. 


Table A-4.14. Service Data for Delete Request 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 
Data STRUCT Class/Instance definition must specify its 


format. 


Success Response Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a successful response to a Delete request 


Table A-4.15. Service Data for Delete Success Response 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 
Data STRUCT Class/Instance definition must specify its 


format. 


Open DeviceNet Vendor Assoc. & ControlNet International A-15 


Appendix A: Explicit Messaging Services Volume 1: CIP Common Specification 


Multiple Service Packet 
Service Code: OAtex 


Performs a set of services as an autonomous sequence. 


Service Requirements 


The following list details requirements associated with the Delete 
service: 


1. Performs services as an autonomous sequence of services. 
2. Performs services in the sequence supplied. 


3. Performs all services, reporting individual responses for each 
one. 


4. Packs responses into the response buffer in the sequence in which 
they were executed. 


5. Aresponse timeout must be implemented for those service 
requests that do not guarantee a response. 


6. Each embedded service may return a success or failure, as 
indicted in the response structure. If one or more service requests 
results in an error this service shall return an error. The error 
code returned shall be 1 Enex (Embedded service error). 


This service allows clients to submit a sequence of ‘embedded’ 
services in a single message packet. The object processing the 
Multiple Service Packet shall not perform any other service until the 
entire sequence of embedded services has been attempted. 


The embedded services are formatted according to their definitions. 
Each embedded service may contain an EPATH. If an EPATH is 
present, the embedded service is passed to the Message Router for 
processing. If an EPATH is not present, the object performing the 
Multiple Service Packet request shall perform the embedded service. 


Request Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a Multiple Service Packet request. 
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Table A-4.16. Service Data for Multiple Service Packet Request 


Name Data Type Description of Parameter 
Number of UINT Number of embedded services in the Service 
Services List. 

Service Offsets | ARRAY of Array of byte offsets to the start of each 
UINT embedded service in the Service List. 


Service List Array of service request structures. The format 


USINT Service code of the request. 


USINT The number of 16 bit words in the 
Request_Path field (next element). 
Padded This is an array of bytes whose contents convey 


EPATH the path of the request (Class ID, Instance ID, 
etc.) for this transaction. 


ARRAY of | Service specific data to be delivered in the 
octet Explicit Messaging Request. If no additional 
data is to be sent with the Explicit Messaging 
Request, then this array will be empty. 


Success Response Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a successful response to a Multiple Service Packet request 


Table A-4.17. Service Data for Multiple Service Packet Response 


Name Data Type Description of Parameter 
Number of | UINT Number of embedded services responses in the 
Responses Response List. 
Response ARRAY of Array of byte offsets to the start of each 
Offsets UINT embedded service response in the Response 

List. 

Response ARRAY of Array of service response structures. The 
List STRUCT of format of the service response follows the 


Message Router Response header defined in 
Chapter 2. 


UINT Reply service code. 

USINT Shall be zero. 

USINT One of the General Status codes listed in 
Appendix B (Status Codes). 

USINT Number of 16 bit words in Additional Status 
array. 

ARRAY of Additional status. 

UINT 


ARRAY of Response data from request or additional error 
octet data if General Status indicated an error. 
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Apply_ Attributes 


Service Code: ODhex 


Causes attribute values whose use is pending to become actively 
used. 


Service Requirements 


The following list details requirements associated with the 
Apply_ Attributes service: 


1. Data for pending attributes must be verified before it is actually 
used. 


2. Ifan error is detected, then an Error Response is returned. 
Otherwise, a successful Apply Attributes response is returned. 


Request Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of an Apply_ Attributes request. 


Table A-4.18. Service Data for Apply_Attributes Request 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 

Data STRUCT Class/Instance definition must specify its 
format. 


Success Response Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a successful response to an Apply_ Attributes 
request 


Table A-4.19. Service Data for Apply_Attributes Success Response 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 

Data STRUCT Class/Instance definition must specify its 
format. 
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Get_Attribute_Single Returns the contents of the specified attribute. 


Service Code: OEnex 
Service Requirements 


The following list details requirements associated with the 
Get Attribute Single service: 


1. The service causes the class/object to return the contents of the 
specified attribute to the requester. 


2. Ifan error is detected, then an Error Response is returned. 
Otherwise, a successful Get Attribute Single response is 
returned along with the requested attribute data. 


Request Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a Get_Attribute_ Single request. 


Table A-4.20. Service Data for Get_Attribute_Single Request 
Name Data Type Description of Parameter 


Attribute ID! USINT Identifies the attribute to be read/returned 


' This parameter shall be present when the target of the request is on a subnet which 
does not support explicit message addressing to the attribute level. If the subnet does 
support attribute level addressing then this parameter shall not be present. In the latter 
case, the data type of the Attribute ID can be either USINT, UINT, or UDINT. 


Success Response Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a successful Get_Attribute Single response. 


Table A-4.21. Service Data for Get_Attribute_Single Success Response 


Name Data Type Description of Parameter 


Attribute Data | Object/class Contains the requested attribute data 
attribute — 
specific Struct 
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Set_Attribute_Single Modifies an attribute value. 


Service Code: 10hex 
Service Requirements 


The following list details requirements associated with the 
Set Attribute Single service: 


1. The attribute data is validated prior to the modification taking 
place. 


2. Ifan error is detected, then an Error Response is returned. 
Otherwise a successful Set Attribute Single response is returned. 


Request Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a Set Attribute Single request. 


Table A-4.22. Service Data for Set_Attribute_Single Request 
Name Data Type Description of Parameter 
Attribute ID! USINT Identifies the attribute to be read/returned 


Attribute Data | Attribute Contains the value to which the specified 
specific attribute is to be modified. 


' This parameter shall be present when the target of the request is on a subnet which 
does not support explicit message addressing to the attribute level. If the subnet does 
support attribute level addressing then this parameter shall not be present. In the latter 
case, the data type of the Attribute ID can be either USINT, UINT, or UDINT. 


Success Response Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a successful response to a Set_Attribute_Single 
request 


Table A-4.23. Service Data for Set_Attribute_Single Success Response 


Name Data Type Description of Parameter 


Object Data | Object/class Contains Class/Instance specific parameters. If 
service— specific | a Class/Instance utilizes this field, then the 
Class/Instance definition must specify its 
format. 
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Find_Next_Object_Instance 


Service Code: 1 I hex 


Release 1.0 


This service is supported at the Class level only. It causes the 
specified Class to search for and return a list of Instance IDs 
associated with existing Object Instances. Existing Objects are those 
that are currently accessible from the CIP subnet. 


Service Requirements 


The following list details requirements associated with the 
Find_Next_Object_Instance service: 


1. The Class utilizes the value specified in the Instance ID of the 
request message to determine the starting point for the search as 
described below: 


e Ifthe Instance ID in the request message is zero (0), then 
the Class starts with the numerically lowest Instance ID. 

e Ifthe Instance ID in the request message is not zero (0), 
then the Class starts with the next Instance ID whose value 
is numerically greater than the specified Instance ID. 

e Ifthe Instance ID in the request message is greater than or 
equal to the numerically highest Instance ID within the 
Class, then the value zero (0) is returned. 


2. The Class returns a list of Instance IDs associated with existing 
Objects beginning at the starting point and continuing in 
ascending Instance ID value order. 


3. The request specifies the maximum number of Instance ID values 
to be returned in the response. The responding Class can return 
any number of Instance IDs less than or equal to the maximum 
specified in the request. 


4. The responding device returns Instance ID value zero (0) to 
indicate that the end of the list has been reached. 


5. Ifan error is detected, then an Error Response is returned. 
Otherwise a successful Find Next Object Instance response is 
returned. 
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The following illustration provides a general example of this service. 
Specific encoding examples are presented in section A-6. 


Find Next_Object_Instance Request [Instance ID = 0] a Class A 


Find Next _Object_Instance Response, Service Data = 1 


Instance Instance Instance 
ID#1 ID #5 ID #8 
Find Next_Object_Instance Request [Instance ID = 2] y 
Find Next_Object_Instance Response, Service Data = 5, 8 
Instance 
ID #9 
Find Next Object Instance Request [Instance ID = 8] / 
Find Next _Object_Instance Response, Service Data = 9, 0 ie ra 


Request Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a Find_Next_Object_Instance request. 


Table A-4.24. Service Data for Find_Next_Object_Instance Request 


Name Data Type Description of Parameter 


Maximum Indicates the maximum number of Instance ID 


USINT maximum 
Returned Values values to be returned in the response message. 


Success Response Service Data Field Parameters 


The following information is specified within the Service Data Field 
of a successful Find Next Object Instance response. 


Table A-4.25. Service Data for Find_Next_Object_Instance Success 
Response 


Name Data Type Description of Parameter 
Number Of List USINT Contains the number of Instance IDs specified 
Members in this response message. 


Instance ID List | Array of UINT | Contains the returned Instance ID List. The 


Instance IDs are returned in 16 bit integer 
fields. 
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Restore 


Service Code: 15hex 


Release 1.0 


Restores the contents of a class/object’s attributes from a storage 
location accessible by the Save service. Attribute data is copied from 
a storage area to the currently active memory area used by the 
class/object. 


Service Requirements 


The following list details requirements associated with the Restore 
service: 


1. Attribute data must be verified before the copy from the “storage 
area” to the “actively used” area is performed. 


2. Ifthe ability to modify an attribute changes based on the state of 
the object, the object definition must provide a detailed 
description of how this service is effected. For example; this 
service could only be supported in a state where all attributes are 
modifiable. Alternatively, the object could ignore the data 
associated with a currently non-modifiable attribute. 


3. Attributes will be modified only if all attribute specific value 
verifications (e.g. range checks, etc.) are successful. The first 
attribute failing verification will be specified in the Additional 
Code parameter of the Error Response message. 


4. Ifany other error is detected, then an Error Response is returned. 


5. Ifall verification checks pass, then the attributes are modified and 
a Restore success response is returned. 


Request Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a Restore request. 


Table A-4.26. Service Data for Restore Request 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 

Data STRUCT Class/Instance definition must specify its 
format. 
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Success Response Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a successful response to a Restore request 


Table A-4.27. Service Data for Restore Success Response 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 

Data STRUCT Class/Instance definition must specify its 
format. 
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Save 


Service Code: 1 6hex 


Release 1.0 


Copies the contents of an class/object’s attributes to a location 
accessible by the Restore service. 
Service Requirements 


The following list details requirements associated with the Save 
service: 


1. The service will report success only after the copy has been 
completed and verified. 


2. Ifan error is detected, then an Error Response is returned. 


Otherwise, a successful Save response is returned. 


Request Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a Save request. 


Table A-4.28. Service Data for Save Request 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 

Data STRUCT Class/Instance definition must specify its 
format. 


Success Response Service Data Field Parameters 


The following information is OPTIONALLY specified within the 
Service Data Field of a successful response to a Save request 


Table A-4.29. Service Data for Save Success Response 


Name Data Type Description of Parameter 


Object Object/class Contains Class/Instance specific parameters. If 
Specific | service— specific | a Class/Instance utilizes this field, then the 
Data STRUCT Class/Instance definition must specify its 


format. 
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No Operation (NOP) This service merely causes the receiving object to return a No 
Operation response. The receiving object does not carry out any 
other internal action. This service can be used to test whether or not 
a particular object is still present and responding without causing a 
state change. 


Service Code: 17hex 
Required Behavior 


The NOP service requires the following behaviors: 


1. Ifthe object to which the request is delivered supports the 
service, then a response whose status indicates success is 
returned. If the object does not support the service, then a 
response indicating an error was detected is returned. 


Request Service Data Field Parameters 


NONE 


Success Response Service Data Field Parameters 


NONE 
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Get_Member 


Service Code: 18hex 


Release 1.0 


Returns member(s) information from within an attribute. 


See Section A-5 for Member Service Protocol details. 


Service Requirements 


The following list details requirements associated with the 
Get_Member service: 


1. The service causes the class/object to return member(s) at the 
specified Member ID of an attribute. 


2. Ifan error is detected, then an Error Response is returned. 
Otherwise, a successful Get_ Member response is returned. 


3. If Member ID is greater than largest existing Member ID, gets the 
one member with the highest Member ID. 


4. Ifthe Member ID value is zero, returns an /nvalid Member ID 
Error Response. To get all members, use a Get_Attribute_Single 
service. 


Request Service Data Field Parameters 


Request Field Required/Optional/Not Present 


Member Data 


Not present 


Success Response Service Data Field Parameters 


Response Field Required/Optional/Not Present 
Member ID Required 
Member Data Required 
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Set_Member 


Service Code: 19hex 


A-28 


Sets member(s) information in an attribute. 


See Section A-5 for Member Service Protocol details. 


Service Requirements 


The following list details requirements associated with the 
Set_Member service: 


1. The service causes the class/object to set member(s) at the 
specified Member ID of an attribute. 


2. The request is checked, and if valid, the member(s) are set to the 
new Member Data. 


3. Ifan error is detected, then an Error Response is returned. 
Otherwise, a successful Set_ Member response is returned. 


4. Ifthe Member ID value is greater than that of the last Member ID 
for the specific attribute, no action occurs and an Invalid Member 
ID Error Response is returned. 


5. If multiple members are specified and fewer members exist at the 
specified Member ID, no action occurs and an Invalid Member 
ID Error Response is returned. 


6. Ifthe Member ID value is zero, an Invalid Member ID Error 
Response is returned. 


Request Service Data Field Parameters 


Request Field Required/Optional/Not Present 


Member Data Required 


Success Response Service Data Field Parameters 


Response Field Required/Optional/Not Present 
Member ID Conditional 
(Required if Member Data is present) 
Member Data Optional 
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Insert_Member 


Service Code: 1 Apex 


Release 1.0 


Inserts member(s) into an attribute. 


See Section A-5 for Member Service Protocol details. 


Service Requirements 


The following list details requirements associated with the 
Insert_Member service: 


1. The service causes the class/object to insert member(s) at the 
specified Member ID of an attribute. The Member IDs of 
members at or following the specified Member ID will change. 


2. The request is checked, and if valid, the member(s) are inserted. 
If member data is not included in the request, the member(s) are 
set to the class/attribute specific default. 


3. Ifan error is detected, then no action is taken and an Error 
Response is returned. Otherwise, a successful Insert_ Member 
response is returned. 


4. Ifthe number of members specified cannot be added to the 
attribute, then a “Resource unavailable” error response is 
returned. 


5. Ifthe Member ID value is greater than that of the last Member ID 
for the specific attribute, appends member(s) to the attribute and 
returns the Member ID where inserted. 


6. Ifthe Member ID value is zero, returns an Invalid Member ID 
Error Response. 


Request Service Data Field Parameters 


Request Field Required/Optional/Not Present 


Member Data Optional 


Success Response Service Data Field Parameters 


Response Field Required/Optional/Not Present 
Member ID Required 
Member Data Optional 
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Remove_Member 


Service Code: 1Bnhex 


A-30 


Removes member(s) from an attribute. 


See Section A-5 for Member Service Protocol details. 


Service Requirements 


The following list details requirements associated with the 
Remove_Member service: 


1. The service causes the class/object to remove member(s) at the 
specified Member ID of an attribute. The Member IDs of 
members following the removed member(s) change. 


2. Ifan error is detected, then no action is taken and an Error 
Response is returned. Otherwise, a successful Remove Member 
response is returned. 


3. If Member ID is greater than largest existing Member ID, the one 
member with the highest Member ID is removed. 


4. If multiple members are specified and fewer members exist at the 
specified Member ID, the member(s) that do exist are removed. 


Request Service Data Field Parameters 


Request Field Required/Optional/Not Present 


Member Data Not present 


Success Response Service Data Field Parameters 


Response Field Required/Optional/Not Present 
Member ID Required 
Member Data Required 
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A-5 


A-5.1 


Release 1.0 


MEMBER SERVICE PROTOCOLS 


Attributes of object classes may consist of arrays of basic data types or structures. To 
manipulate members of an array, the following member services use the protocols defined in 
this section: 


e Get Member 

e Set_ Member 

e Insert_Member 

e Remove Member 


The first member in an array is specified by a Member ID value of one (1). 


Member ID/EX Description 


Two message formats are defined for member services: basic and extended. Within the 
extended format, there exist up to 255 protocol options. The message format is selected by the 
most significant bit of the Member ID. When a subnet does not support Attribute and Member 
level addressing, the Member ID/EX parameter is sent as a 16 bit (WORD) parameter within 
the service data. If the subnet does support Attribute and Member level addressing, the 
Member ID/EX parameter is sent within the Logical Segment and can be either 8, 16, or 32 bits 
(BYTE, WORD, DWORD). The following table defines the bits contained within the Member 
ID/EX field when sent as a WORD. 


Table A-5.1. Member ID/EX Description (WORD) 


Bits 


es ee eee 


Member ID Bits 0-7 


EX Member ID Bits 8-14 


The lower fifteen bits (0-14) of the Member ID/EX field identify the member to be 
manipulated. Bit 15 (EX), selects either the basic (EX=0) or extended (EX=1) message format. 
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A-5.2 Member Request Message - Basic 


The following table illustrates the basic Member Request Message service data format. 
Table A-5.2. Service Data for Basic Format Member Request Messages 


Name Data Type Description of Parameter 


Attribute ID! | USINT Identifies the attribute the member 1s to be serviced. 


The lower 15 bits identifies the Member ID identifies attribute of the 


Member ID/ | WORD new member to be serviced. If the value is zero (0) the service used 
2 


EX determines the behavior. 
Extended Protocol Option EX = 0 (Bit 15) 
Member | Member This field is required by some services, see individual service 
Data specific descriptions. 
(conditional) 


' This parameter shall be present when the target of the request is on a subnet which does not support 
explicit message addressing to the attribute level. Ifthe subnet does support attribute level addressing 
then this parameter shall not be present. In the latter case, the data type of the Attribute ID can be 
either USINT, UINT, or UDINT. 


° This parameter shall be present when the target of the request is on a subnet which does not support 
explicit message addressing to the member or attribute level. If the subnet does support attribute and 
member level addressing then this parameter shall not be present. In this latter case, the data type of the 
Member ID/EX can be either BYTE, WORD, or DWORD with the most significant bit being the 
Extended Protocol Option parameter and the remaining bits being the Member ID. 


Table A-5.3. Service Data for Basic Format Member Response Messages 


Name Data Type Description of Parameter 


Member ID UINT The Member ID of the member serviced. 
(conditional) This field is required by some services, see 
individual service descriptions. This field is 
required if the Member Data field is present. 
Member Data | Member specific This field is required by some services, see 
ots individual service descriptions. 
(conditional) 


A-5.3 Member Request Message - Extended 


If the Extended protocol bit [EX] of the Member ID/EX field is set to a one [1], the byte 
following the Member ID/EX defines the remainder of the protocol. 


The Extended Protocol ID value conforms to the standard reserved ranges for open/vendor 
specific/ reserved ranges. 
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Table A-5.4. Service Data for Extended Format Member Request Messages 


Name Data Type Description of Parameter 
Attribute ID! USINT Identifies the attribute the member is to be serviced. 


The lower 15 bits identifies the Member ID identifies 
Member ID / EX? | WORD attribute of the new member to be serviced. If the value is 
zero (0) the service used determines the behavior. 


Extended Protocol Option EX= 1 (Bit 15) 


Selects the extended protocol used for the remainder of 
sae USN message, per Extended Protocol ID table. 


Protocol specific Additional request data is defined by the extended protocol. 


' This parameter shall be present when the target of the request is on a subnet which does not support explicit 
message addressing to the attribute level. If the subnet does support attribute level addressing then this 
parameter shall not be present. In the latter case, the data type of the Attribute ID can be either USINT, UINT, 
or UDINT. 


* This parameter shall be present when the target of the request is on a subnet which does not support explicit 
message addressing to the member or attribute level. If the subnet does support attribute and member level 
addressing then this parameter shall not be present. In this latter case, the data type of the Member ID/EX can 
be either BYTE, WORD, or DWORD with the most significant bit being the Extended Protocol Option 
parameter and the remaining bits being the Member ID. 


Table A-5.5. Service Data for Extended Format Member Response Messages 


Name Data Type Description of Parameter 


Protocol specific Response data is defined by the extended protocol option. 


The following table contains a list of the currently defined values for the Extended Protocol ID. 


Table A-5.6. Extended Protocol ID 


Value Description 

0 Reserved for future CIP use 

1 Multiple Sequential Members 
2-63hex Reserved for future CIP use 


64hex-C7hex 
C8hex-FFhex 


Vendor Specific 
Reserved for future CIP use 
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A-5.3.1 


A-34 


Multiple Sequential Members - Extended Protocol 
When the Extended Protocol ID is set to Multiple Sequential Members [1], the following 
protocol is used: 


Table A-5.7. Service Data for Multiple Sequential Member Request Messages 


Name Data Type Description of Parameter 
Attribute ID! | USINT Identifies the attribute the member is to be serviced. 


The lower 15 bits identifies the Member ID identifies attribute of the 
Member ID/ | WORD new member to be serviced. If the value is zero (0) the service used 
EX? determines the behavior. 
Extended Protocol Option EX= 1 (Bit 15) 


Extended USINT [01] Selects the Multiple Sequential Members protocol option 
Protocol ID 
Number of =| UINT The number of members to be serviced. 
Members 


Member Data | Member specific | Multiple sequential Member Data 


This field is required by some services, see individual service 
descriptions. 


(conditional) 


' This parameter shall be present when the target of the request is on a subnet which does not support 
explicit message addressing to the attribute level. Ifthe subnet does support attribute level addressing 
then this parameter shall not be present. In this latter case, the data type of the Attribute ID can be either 
USINT, UINT, or UDINT. 


* This parameter shall be present when the target of the request is on a subnet which does not support 
explicit message addressing to the member or attribute level. If the subnet does support attribute and 
member level addressing then this parameter shall not be present. In the latter case, the data type of the 
Member ID/EX can be either BYTE, WORD, or DWORD with the most significant bit being the 
Extended Protocol Option parameter and the remaining bits being the Member ID. 


Table A-5.8. Service Data for Member Response Messages (Extended Protocol) 


Name Data Type Description of Parameter 
Number of UINT The number of members serviced. This field is 
Members required. 
Member ID UINT The Member ID of the first member serviced. 
(conditional) This field is required by some services, see 
individual service descriptions. This field is required 
if the Member Data field is present. 
Member Data | Member specific Multiple sequential Member Data 
(conditional) This field is required by some services, see 


individual service descriptions. 
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A-6 CIP ENCODING EXAMPLES 


The example object definitions presented in the following section are used as the basis for 
providing CIP Common Service encoding examples. 


A-6.1 Example Object Class Definitions 
Table A-6.1 lists the class codes of the example Object Classes. 
Class A Class B Glass C Chas D 


Table A-6.1. Class ID Codes For Example Classes 


Class Name | Class ID Code 
Class A 70hex 
Class B T1hex 
Class C 72hex 
Class D 73hex 


The tables below illustrate the attributes associated with Object Instances within these classes. 


Table A-6.2. Class A Object Instance Attributes 


Attribute Attribute Description 
Name ID Method 
attribute_1 1 UINT Gettable/ | Allows values in range of 1 - 9 
Settable 


attribute _2 SINT No limit to value 


attribute_3 3 DINT Gettable/ | No limit to value 
Settable 
Table A-6.3. Class B Object Instance Attributes 
Attribute Attribute | Format Access Attribute Description 
Name ID Method 
attribute_1 1 DINT Gettable/ No limit to value 
Settable 


attribute _2 No limit to value 


attribute_3 Value limited to range of 10 - 20 
Settable 

attribute_4 4 UINT Gettable/ Value limited to range of 0 - 9 
Settable 


Table A-6.4. Class C Object Instance Attributes 


Attribute Attribute | Format Access Attribute Description 
Name ID Method 


attribute_1 No limit to value 
attribute_2 No limit to value 


attribute_3 3 UINT Gettable/ Allows values in range of 1 - 5 
Settable 
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Table A-6.5. Class D Object Instance Attributes 


Attribute Attribute | Format Access Attribute Description 
Name ID Method 
attribute_1 1 USINT _ | Gettable/ No limit to value 
Settable 
attribute_2 2 UINT Gettable/ No limit to value 
Settable 


A-6.2 Encoding Examples 


Examples showing how the CIP Common Services are encoded are provided on the following 
pages. Note that the examples assume that a Explicit Messaging Connection has already 
been established and, as such, the Connection IDs associated with the Explicit Messaging 
Connections have already been agreed upon. 


A-36 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Appendix A: Explicit Messaging Services 


Get_Attributes_ All The Client wants to read all of the attributes from Instance #1 within 
Class D with one request. Assume the Explicit Messaging 
Connection was established across Group 3 and the Message Body 
Format was defined by the Server as DeviceNet (8/8). 


Client Server 
MAC ID=0A MAC ID =2 


Group 3 Message 


Assume the Client allocated Group 3 Message ID value 5 
Source MAC ID = 0A 
Frag = 0, Transaction ID = 1, Destination MAC ID = 2 
Service = Get_Attributes_All Request 


Class D (class code = 73 hex) 
| Instance ID = 01 
Identifier = 11 101 001010, Data= 42 01 73 01 > 


Group 3 Message 


Assume the Server allocated Group 3 Message ID value 0 

Source MAC ID =2 

Frag = 0, Transaction ID = 1, Destination MAC ID = 0A 
Service = Get_Attributes_All Response (Success) 


Attribute Data (attribute_1 = 5, attribute_2 = 7) 


€ Identifier = 11 000 000010, Data=4A 81 050700 


Release 1.0 Open DeviceNet Vendor Assoc. & ControlNet International A-37 


Appendix A: Explicit Messaging Services Volume 1: CIP Common Specification 


Set_Attributes_All 


Client 


The Client wants to modify all of the attributes from Instance #2 
within Class D with one request. Assume the Explicit Messaging 
Connection was established across Group 3 and the Message Body 
Format was defined by the Server as DeviceNet (8/8). 


Server 


MAC ID=0A MAC ID =2 


A-38 


Group 3 Message 


Assume the Client allocated Group 3 Message ID value 4 


Source MAC ID=0A 
Frag = 0, Transaction ID = 1, Destination MAC ID = 2 


Service = Set_Attributes_All Request 


Class D (class code = 73 hex) 
Instance ID = 02 
| Attribute Data (attribute_1 = 6, attribute_2 = 8) 


Identifier = 11 100 001010, Data= 42 02 73 02 060800 >» 


Group 3 Message 


Assume the Server allocated Group 3 Message ID value 4 (same as the Client !!) 


[——_ Source MAC ID = 2 
Frag = 0, Transaction ID = 1, Destination MAC ID = 0A 


Service = Set_Attributes_All Response (Success) 


€ Identifier = 11 100 000010, Data=4A 82 
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Reset The Client wants to Reset Instance #4 within Class B. Assume the 
Explicit Messaging Connection was established across Group 3 and 


the Message Body Format was defined by the Server as DeviceNet 
(16/16). 


Client Server 
MAC ID=0A MAC ID=2 
- Group 3 Message 


Assume the Client allocated Group 3 Message ID value 3 


Source MAC ID=0A 
Frag = 0, Transaction ID = 0, Destination MAC ID = 2 


Service = Reset Request 


Class B (class code = 71 hex) 
| = Instance ID = 04 
Identifier = 11 011 001010, Data=02 05 7100 0400 > 


Group 3 Message 


Assume the Server allocated Group 3 Message ID value 2 


[——_ Source MAC ID = 2 
Frag = 0, Transaction ID = 0, Destination MAC ID = 0A 


Service = Reset Response (Success) 


€ Identifier = 11 010 000010, Data=0A_ 85 
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Start The Client wants to Start Instance #5 within Class C. Assume the 
Explicit Messaging Connection was established across Group | and 


the Message Body Format was defined by the Server as DeviceNet 
(8/16). 


Client Server 
MAC ID=0A MAC ID =2 


Group 1 Message 
Assume the Client allocated Group 1 Message ID value | 


Source MAC ID=0A 
Frag = 0, Transaction ID = 1, Destination MAC ID = 2 


Service = Start Request 
Class C (class code = 72 hex) 
| Instance ID = 05 


Identifier = 0 0001 001010, Data = 42 06 72 0500 » 


Group 1 Message 


Assume the Server allocated Group 1 Message ID value 9 


Source MAC ID = 2 
Frag = 0, Transaction ID = 1, Destination MAC ID = 0A 


Service = Start Response (Success) 


€ Identifier = 0 1001 000010, Data=4A_ 86 
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Stop The Client wants to Stop Instance #9 within Class B. Assume the 
Explicit Messaging Connection was established across Group 3 and 
the Message Body Format was defined by the Server as DeviceNet 
(8/8). 


Client Server 
MAC ID=0A MAC ID=2 
- Group 3 Message 


Assume the Client allocated Group 3 Message ID value 5 


Source MAC ID=0A 
Frag = 0, Transaction ID = 0, Destination MAC ID = 2 


Service = Stop Request 
Class B (class code = 71 hex) 
| Instance ID = 09 


Identifier = 11 101 001010, Data= 02 07 _71 09 > 


Group 3 Message 


Assume the Server allocated Group 3 Message ID value 0 


-—— Source MAC ID = 2 
Frag = 0, Transaction ID = 0, Destination MAC ID = 0A 


Service = Stop Response (Success) 


€ Identifier = 11 000 000010, Data=0A_ 87 
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Create The Client wants to Create an instance within Class A. Assume the 
Explicit Messaging Connection was established across Group 2 and 
the Message Body Format was defined by the Server as DeviceNet 
(8/8) 


Client Server 


MAC ID=0A fj Steep 2 Messe MAC ID=2 
Destination MAC ID =2 


Assume the Server allocated Group 2 Message ID 2 to the Client. 
Frag = 0, Transaction ID = 0, Souree MAC ID = 0A 
Service = Create Request 

Class A (class code = 70 hex) 


i Instance ID = 00 (request sent to class vs. a specific Object 


Instance) 


Identifier = 10 000010 010, Data=0A 08 70 00 » 


-— Group 2 Message 
Source MAC ID = 2 


Assume the Server allocated Group 2 Message ID value 3 for itself 
Frag = 0, Transaction ID = 0, Destination MAC ID = 0A 


Service = Create Response (Success) 
| Instance ID of newly created Object = 6 


€ Identifier = 10 000010 011, Data=0A _ 88 0600 
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Delete The Client wants to Delete Instance #3 within Class B. Assume the 
Explicit Messaging Connection was established across Group 3 and 


the Message Body Format was defined by the Server as DeviceNet 
(8/16). 


Client Server 
MAC ID=0A MAC ID =2 
Group 3 Message 


Assume the Client allocated Group 3 Message ID value 5 


Source MAC ID=0A 
Frag = 0, Transaction ID = 1, Destination MAC ID = 2 
Service = Delete Request 


Class B (class code = 71 hex) 
| Instance ID = 03 


Identifier = 11 101 001010, Data= 42 09 71 0300 > 


Group 3 Message 


Assume the Server allocated Group 3 Message ID value 0 


Source MAC ID =2 
Frag = 0, Transaction ID = 1, Destination MAC ID = 0A 


Service = Delete Response (Success) 


€ Identifier = 11 000 000010, Data=4A 89 
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Apply Attributes The Client wants to send an Apply Attributes to Instance #2 within 
Class C. Assume the Explicit Messaging Connection was established 
across Group 2 and the Message Body Format was defined by the 
Server as DeviceNet (16/16). 


Client —- Server 
MAC ID=0A ena auniies MAC ID =2 
[Destination MAC ID =2 
"—— Assume the Server allocated Group 2 Message ID | to the Client. 
Frag = 0, Transaction ID = 0, Source MAC ID=0A 


Service = Apply Attributes Request 


Class C (class code = 72 hex) 
| a Instance ID = 02 


Identifier = 10 000010 001, Data=0A_0D_7200_0200 > 


Group 2 Message 
Source MAC ID = 2 


Assume the Server allocated Group 2 Message ID value 4 for itself 


Frag = 0, Transaction ID = 0, Destination MAC ID = 0A 
Service = Apply Attributes Response (Success) 


€ Identifier = 10 000010 100, Data= 0A 8D 
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Get_Attribute_Single The Client wants to read Attribute #1 within Instance #2 of Class A. 
Assume the Explicit Messaging Connection was established across 


Group | and the Message Body Format was defined by the Server as 
DeviceNet (8/8). 


Client Server 
MAC ID=0A MAC ID =2 
- Group | Message 
Assume the Client allocated Group 1 Message ID value 3 
Source MAC ID=0A 
Frag = 0, Transaction ID = 0, Destination MAC ID = 2 
Service = Get Attribute Single Request 


Class A (class code = 70 hex) 
Instance ID = 02 
[—_ Attribute ID = 01 


Identifier = 0 0011 001010, Data= 02 0E 70 02 01 > 


Group | Message 


Assume the Server allocated Group 1 Message ID value 8 


Source MAC ID =2 
Frag = 0, Transaction ID = 0, Destination MAC ID = 0A 


Service = Get Attribute Single Response (Success) 
The Attribute data (value = 9) 


€ Identifier = 0 1000 000010, Data= 0A 8E 0900 
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Set_Attribute_Single The Client wants to modify Attribute #1 within Instance #2 of Class 
A. Assume the Explicit Messaging Connection was established 


across Group 2 and the Message Body Format was defined by the 
Server as DeviceNet (8/16). 


AC IE /~ Group 2M Server 
MAC ID=0A roup essage 


Destination MAC ID = 2 we 
Assume the Server allocated Group 2 Message ID | to the Client. 

Frag = 0, Transaction ID = 0, Source MAC ID=0A 

| Service = Set Attribute Single 


Class A (class code = 70 hex) 
Instance ID = 02 


Attribute ID = 01 
| I Attribute Data (value = 3) 


Identifier = 10 000010 001, Data=0A_ 10 70 0200 01 0300 > 
Group 2 Message 
Source MAC ID = 2 


Assume the Server allocated Group 2 Message ID value 4 for itself 


Frag = 0, Transaction ID = 0, Destination MAC ID = 0A 


Service = Set Attribute Single Response (Success) 


€ Identifier = 10 000010 100, Data =0A_90 
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Find_Next_Object_Instance The Client wants to read the list of Instance IDs associated with 


Client 


existing Objects within Class A. Assume the Explicit Messaging 
Connection was established across Group 2 and the Message Body 
Format was defined by the Server as DeviceNet (8/8). Assume also 
that the Instance IDs O1pex and 15pe x exist. 


Server 


MAC ID=0A fe Seep ise ste MAC ID =2 


Release 1.0 


; Destination MAC ID = 2 


Assume the Server allocated Group 2 Message ID | to the Client. 
Frag = 0, Transaction ID = 0, Source MAC ID =0A 


Service = Find Next Object Instance Request 


Class A (class code = 70 hex) 
Instance ID = 00 
| | Maximum Returned Values = 2 


Identifier = 10 000010 001, Data=0A 11 70 00 02 » 


Group 2 Message 
Source MAC ID =2 


Assume the Server allocated Group 2 Message ID value 4 for itself 


Frag = 0, Transaction ID = 0, Destination MAC ID = 0A 


Service = Find Next Object Instance Response (Success) 
Number Of List Members = 2 
| rT. Instance ID values 01 and 15 
< Identifier = 10 000010 100, Data=0A 91 02 0100 1500 


| Group 2 Message 

Destination MAC ID = 2 

Assume the Server allocated Group 2 Message ID | to the Client. 
"—— Frag = 0, Transaction ID = 0, Source MAC ID =0A 


Service = Find Next Object Instance 


Class A (class code = 70 hex) 
Instance ID = 15 
| [ Maximum Returned Instance IDs = 2 


Identifier = 10 000010 001, Data=0A 11 70 15 02 ¥ 


Group 2 Message 
Source MAC ID =2 


Assume the Server allocated Group 2 Message ID value 4 for itself 


Frag = 0, Transaction ID = 0, Destination MAC ID = 0A 


Service = Find Next Object Instance Response (Success) 
Number Of List Members = 1 
| | Instance ID value 0 (end of list) 


€ Identifier = 10 000010 100, Data=0A_91 01 0000 
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Restore The Client wants to send a Restore Request to Instance #3 within 
Class B. Assume the Explicit Messaging Connection was established 
across Group 3 and the Message Body Format was defined by the 
Server as DeviceNet (8/8). 


Client Server 
MAC ID=0A MAC ID =2 


Group 3 Message 


Assume the Client allocated Group 3 Message ID value 5 


Source MAC ID=0A 
Frag = 0, Transaction ID = 1, Destination MAC ID = 2 
Service = Restore Request 


Class B (class code = 71 hex) 
| Instance ID = 03 
Identifier = 11 101 001010, Data= 42 15 71 03 > 


Group 3 Message 


Assume the Server allocated Group 3 Message ID value 0 

[—— Source MAC ID = 2 

Frag = 0, Transaction ID = 1, Destination MAC ID = 0A 
Service = Restore Response (Success) 


€ Identifier = 11 000 000010, Data=4A 95 
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Save 


Client 


The Client wants to send a Save Request to Instance #5 within Class 
C. Assume the Explicit Messaging Connection was established 
across Group | and the Message Body Format was defined by the 
Server as DeviceNet (16/16). 


Server 


MAC ID=0A MAC ID =2 


Release 1.0 


Group 1 Message 
Assume the Client allocated Group 1 Message ID value | 


Source MAC ID=0A 
Frag = 0, Transaction ID = 1, Destination MAC ID = 2 
Service = Save Request 


Class C (class code = 72 hex) 
| = Instance ID = 05 
Identifier = 0 0001 001010, Data= 42 16 7200 0500 > 


Group 1 Message 


Assume the Server allocated Group 1 Message ID value 9 
Source MAC ID =2 


Frag = 0, Transaction ID = 1, Destination MAC ID = 0A 
Service = Save Response (Success) 


€ Identifier = 0 1001 000010, Data=4A_ 96 
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No Operation 


Client 


The Client wants to send a No Operation (NOP) to Instance #2 within 
Class C. Assume the Explicit Messaging Connection was established 
across Group 2 and the Message Body Format was defined by the 
Server as DeviceNet (16/16). 


Server 


MAC ID=0A fa rears Mester MAC ID =2 


A-50 


j Destination MAC ID =2 


-—— Assume the Server allocated Group 2 Message ID | to the Client. 
Frag = 0, Transaction ID = 0, Source MAC ID = 0A (Destination in Identifier) 
Service = No Operation Request 
Class C (class code = 72 hex) 


a Instance ID = 02 


Identifier = 10 000010 001, Data=0A_17 7200 0200 > 


Group 2 Message 
Source MAC ID = 2 


Assume the Server allocated Group 2 Message ID value 4 for itself 


Frag = 0, Transaction ID = 0, Destination MAC ID = 0A (Source in Identifier) 
Service = No Operation Response (Success) 


< Identifier = 10 000010 100, Data=0A_97 
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Error Response 


Release 1.0 


Client 
MAC ID=0A 


Appendix A: Explicit Messaging Services 


The Client wants to Reset Instance #1 within Class D. Assume the 
Explicit Messaging Connection was established across Group | and 
the Message Body Format was defined by the Server as DeviceNet 
(8/8). Assume also that Objects within Class D do not support the 
Reset service. 


Server 
MAC ID =2 


Group | Message 
Assume the Client allocated Group 1 Message ID value 3 
Source MAC ID = 0A 


Frag = 0, Transaction ID = 1, Destination MAC ID = 2 
Service = Reset Request 


Class D (class code = 73 hex) 
| [ Instance ID = 1 


Identifier = 0 0011 001010, Data=42 05 73 01 > 


Group | Message 
Assume the Server allocated Group 1 Message ID value OF 


Source MAC ID =2 
Frag = 0, Transaction ID = 1, Destination MAC ID = 0A 
Service = Error Response 
General Error Code (Service Not Supported) 
[ Additional Code (Object specific meaning) 


< Identifier = 0 1111 000010, Data=4A 94 08 05 
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Get_Member The Client wants to read Member #4 of Attribute #3 within Instance 
#2 of Class D. Assume the Explicit Messaging Connection was 
established across Group | and the Message Body Format was 
defined by the Server as DeviceNet (8/8). 


Client Server 
MAC ID=0A MAC ID = 02 


Group 1 Message 
Message ID (3) 
Source MAC ID (OA) 


Non-Frag (0), Transaction ID (0), Destination MAC ID (02) 
Request (0), Service = Get_Member (18) 
Class D (class code = 73) 
Instance (02) 
Attribute ID (03) 


Member ID/EX (04) 
(EX=0, basic format) 


Identifier = 0 0011 001010 Data Field = 02 18 73 02 03 04 


Group 1 Message 
Message ID (8) 


Source MAC ID (02) 
Non-Frag (0), Transaction ID (0), Destination MAC ID (OA) 
Response (1), Service = Get_Member (18) 
oem ID/EX (04) 
Member Data (value = 22) 


Identifier = 0 1000 000010 Data Field = 0A 98 | — a 
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Set_Member The Client wants to modify Member #5 of Attribute #3 within 
Instance #1 of Class D. Assume the Explicit Messaging Connection 
was established across Group 2 and the Message Body Format was 
defined by the Server as DeviceNet (8/8). 


Client Server 
MAC ID =0A MAC ID = 02 


Group 2 Message 
Destination MAC ID (02) 


Message ID (1) 


Non-Frag (0), Transaction ID (0), Source MAC ID (0A) 
Request (0), Service = Set_Member (19) 
Class D (class code = 73) 
Instance (01) 
Attribute ID (03) 


Member ID (05) 
(EX=0, basic format) 


ae Member Data (5D) 


Identifier = 10 000010 001 Data Field = 0A 19 73 01 03 05 5D 


Group 2 Message 
Source MAC ID (02) 
Message ID (4) 


Non-Frag (0), Transaction ID (0), Destination MAC ID (0A) 
| i-- Response (1), Service = Set_Member (19) 


Identifier = 10 000010 100 Data Field = 0A 99 
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Insert_ Member The Client wants to Add Member #14 of Attribute #3 within 


Instance #3 of Class D. Assume the Explicit Messaging Connection 
was established across Group | and the Message Body Format was 


defined by the Server as DeviceNet (8/8). 


Client Server 
MAC ID=0A MAC ID = 02 


Group 1 Message 
Message ID (3) 
Source MAC ID (OA) 


Non-Frag (0), Transaction ID (0), Destination MAC ID (02) 
Request (0), Service = Insert_Member (1A) 
Class D (class code = 73) 
Instance (03) 
Attribute ID (03) 


Member ID/EX (14) 
| (EX=0, basic format) 


Identifier = 0 0011001010 Data Field = 02 1A 73 03 03 14 


Group 1 Message 
Message ID (8) 


Source MAC ID (02) 
Non-Frag (0), Transaction ID (0), Destination MAC ID (OA) 
Response (1), Service = Insert_Member (1A) 
| ; : Member ID (14) 


Identifier = 0 1000 000010 Data Field = 0A 9A 14 
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Remove_Member The Client wants to remove Member #9 of Attribute #3 within 
Instance #1 of Class D. Assume the Explicit Messaging Connection 
was established across Group 2 and the Message Body Format was 
defined by the Server as DeviceNet (8/8). 


Client Server 
MAC ID =0A MAC ID = 02 


Group 2 Message 


Destination MAC ID (02) 


Message ID (1) 


Non-Frag (0), Transaction ID (0), Source MAC ID (0A) 
Request (0), Service = Remove_Member (1B) 
Class D (class code = 73) 
Instance (01) 
Attribute ID (03) 


Member ID/EX (09) 
(EX=0, basic format) 


Identifier = 10 000010 001 Data Field = 0A 1B 73 01 03 09 


Group 2 Message 
Source MAC ID (02) 
Message ID (4) 


Non-Frag (0), Transaction ID (0), Destination MAC ID (0A) 


Response (1), Service = Remove_Member (1B) 


| | . Member Information (value = A5) 


Identifier = 10 000010 100 Data Field = 0A 9B A5 
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B-1. General status codes 


The following table lists the Status Codes that may be present in the General Status Code field 
of an Error Response message. Note that the Extended Code Field is available for use in further 
describing any General Status Code. Extended Status Codes are unique to each General Status 
Code within each object. Each object shall manage the extended status values and value ranges 
(including vendor specific). All extended status values are reserved unless otherwise indicated 
within the object definition. 


Table B-1.1. CIP General Status Codes 


General 


Status Name Description of Status 
Status Code 


Resource unavailable Resources needed for the object to perform the requested service were 


unavailable 


Invalid parameter value See Status Code 0x20, which is the preferred value to use for this condition. 


The path segment identifier or the segment syntax was not understood by the 
processing node. Path processing shall stop when a path segment error is 
encountered. 


The path is referencing an object class, instance or structure element that is not 
known or is not contained in the processing node. Path processing shall stop 
when a path destination unknown error is encountered. 


Already in requested 
mode/state 


Object already exists 


Attribute not settable A request to modify a non-modifiable attribute was received. 
Privilege violation A permission/privilege check failed 


10 Device state conflict The device’s current mode/state prohibits the execution of the requested 
service. 

11 Reply data too large The data to be transmitted in the response buffer is larger than the allocated 
response buffer 


Fragmentation of a The service specified an operation that is going to fragment a primitive data 
primitive value value, i.e. half a REAL data type. 


Release 1.0 Open DeviceNet Vendor Assoc. & ControlNet International B-3 


Appendix B: Status Codes Volume 1: CIP Common Specification 


aoe Description of Status 
(in hex) 
17 Service fragmentation The fragmentation sequence for this service is not currently active for this 
sequence not in progress data. 


18 No stored attribute data The attribute data of this object was not saved prior to the requested service. 


19 Store operation failure The attribute data of this object was not saved due to a failure during the 
attempt. 

1A Routing failure, request The service request packet was too large for transmission on a network in the 
packet too large path to the destination. The routing device was forced to abort the service. 

1B Routing failure, response The service response packet was too large for transmission on a network in the 
packet too large path from the destination. The routing device was forced to abort the service. 

1C Missing attribute list entry | The service did not supply an attribute in a list of attributes that was needed by 
data the service to perform the requested behaviour. 

1D 


Invalid attribute value list | The service is returning the list of attributes supplied with status information 
for those attributes that were invalid. 


Embedded service error An embedded service resulted in an error. 
1F 


Vendor specific error A vendor specific error has been encountered. The Additional Code Field of 
the Error Response defines the particular error encountered. Use of this 
General Error Code should only be performed when none of the Error Codes 
presented in this table or within an Object Class definition accurately reflect 
the error. 


Invalid parameter A parameter associated with the request was invalid. This code is used when a 
parameter does not meet the requirements of this specification and/or the 
requirements defined in an Application Object Specification. 


Write-once value or An attempt was made to write to a write-once medium (e.g. WORM drive, 
medium already written PROM) that has already been written, or to modify a value that cannot be 
changed once established. 


Invalid Reply Received An invalid reply is received (e.g. reply service code does not match the request 
service code, or reply message is shorter than the minimum expected reply 
size). This status code can serve for other causes of invalid replies. 


ee Reserved by CIP for future extensions 


Key Failure in path The Key Segment that was included as the first segment in the path does not 
match the destination module. The object specific status shall indicate which 
part of the key check failed. 


Path Size Invalid The size of the path which was sent with the Service Request is either not large 
enough to allow the Request to be routed to an object or too much routing data 
was included. 


Unexpected attribute in list | An attempt was made to set an attribute that is not able to be set at this time. 


Invalid Member ID The Member ID specified in the request does not exist in the specified 
Class/Instance/Attribute 


Member not settable A request to modify a non-modifiable member was received 


Group 2 only server general | This error code may only be reported by DeviceNet group 2 only servers with 
failure 4K or less code space and only in place of Service not supported, Attribute 
not supported and Attribute not settable. 


2B - CF Po Reserved by CIP for future extensions 


DO - FF Reserved for Object Class | This range of error codes is to be used to indicate Object Class specific errors. 
and service errors Use of this range should only be performed when none of the Error Codes 
presented in this table accurately reflect the error that was encountered. 


27 
28 
29 


tN 
> 
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C-1 
C-1.1 


C-1.2 


Release 1.0 


ABSTRACT SYNTAX ENCODING FOR SEGMENT TYPES 
CIP Segments 


This section specifies the encoding for CIP segments. A CIP segment is a stream of encoded 
items used to reference, describe, and/or configure a specific CIP entity. Segments are usually 
grouped together in order to provide complete information. 


The encoding used for CIP segments has the following relationship with the encoding used to 
report CIP data types, thus allowing both to be intermixed: 


00-9F hex Encoding for Segments 


AO-DF hex Encoding for Data Type Reporting 
E0-FF hex Reserved for future use 


A segment contains information indicating what segment type is specified, the format of the 
segment data, and the actual segment data. Encoding for the following segment types is 
described in section C-1.4: 


e Port segment — used for routing from one subnet to another 

e Logical segment - logical reference information (such as class/instance/attribute IDs) 
e Network segment 

e Symbolic segment - symbolic name 

e Data segment - embedded data (such as configuration data) 


Rules for how the segments are ordered and the interpretation of their meaning are described in 
section C-1.5. 


Usage of Segments for Paths 


A common use of CIP segments is to specify relationships among different objects. A value 
used to specify such a relationship is referred to as a path. A path attribute consists of multiple 
segments, and typically references the class, instance, and attribute of another object. A path 
has data type EPATH. 


Some examples of how paths are used include: 


e InConnection and Connection Manager Objects, paths indicate the object(s) to/from 
which I/O data is moved. 

e In Assembly Objects, paths indicate the attributes in other objects which are used to 
form the assembled I/O data. 


e In Parameter Objects, paths indicate the actual attribute in another object which is being 
described by the Parameter Object. 


An example of a path attribute is shown in Figure C.1. For an example encoding for such a 
path, refer to section C-1.4. 
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Figure C-1.1: Example Path Attribute 


Object Referenced by 
Path 


Attribute Referenced by 
Path 


Path Attribute 


Logical Data 
Segments | Segment 


Object Specific Configuration Data 


Logical Reference to 
Class / Instance / Attribute 


C-1.3 Path Format 
A path (data type EPATH) can be represented in two different formats: 
Padded Path (indicated as data type Padded EPATH) 
Packed Path (indicated as data type Packed EPATH) 
Each segment of a Padded Path shall be 16-bit word aligned. If a pad byte is required to 
achieve the alignment, the segment shall specify the location of the pad byte. A Packed Path 


shall not contain any pad bytes. When a component is defined as data type EPATH, it shall 
indicate the format (Packed or Padded). 
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C-1.4 


C-1.4.1 


Release 1.0 


Segment Type 


Each segment of an encoding contains a segment type/format byte which indicates how the 
segment is to be interpreted. The segment type/format information is contained in the first byte 
of the segment and, as such, the first byte of any encoding contains a segment type/format byte. 


Segment Type Segment Format 
7 6 5 4. 23%, 2 1 0 


The Segment Type bits are described below: 


Segment Type 
7 6 5 
0 0 0 Port Segment 
0 0 1 Logical Segment 
0 1 0 Network Segment 
0 1 1 Symbolic Segment 
1 0 0 Data Segment 
1 0 Data Type (constructed, see C-2.2) 
1 1 0 Data Type (elementary, see C-2.1) 


1 1 1 Reserved for future use 


The meaning of the Segment Format bits is based on the specified Segment Type. 


The Port Segment, Logical Segment, Network Segment, Symbolic Segment, and Data Segment 
are described in sections C-1.4.1 to C-1.4.5. 


PORT SEGMENT 
The port segment shall indicate 


Communication port through which to leave the node; 
Link address of the next device in the routing path. 
The Port Segment is formatted as defined in the figure below. The bit representation is from 


high bit to low bit, left to right. The byte representation is from low byte to high byte, top to 
bottom and left to right. 
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Port Segment 


Segment Extended Link Port 
Address Size Identifier 
Optional Link 
Address Size 


eee 


Optional Extended Port 
Identifier (2 Bytes) 


i 


Link Address 


Bit 4, the Extended Link Address Size bit, shall be set to 0 if the link address is one byte. Bit 
4 shall be set to | if the link address is larger than one byte. If the link address is larger than 
one byte, its size in bytes shall be in the second byte of the Port Segment. 


Bits 0 — 3, the Port Identifier, shall indicate through which port to leave the node. The Port 
Identifier shall specify a Port Number or an escape to an extended port identifier when the 
module can support more than 14 ports. The list below defines rules pertinent to Port 
Identification/Port Number and Link Address values: 


Port Number 0 shall be reserved. 
Port Number | shall only be used to represent a back-plane port. 


If the Port Identifier is 15, then a 16-bit field, called the Extended Port Identifier, shall be the 
next part of the Port Segment (following the optional Link Address Size if present); otherwise, 
the value of the Port Identifier shall be the Port Number. 


The Port Number shall be followed by a Link Address whose format depends on the type of 
network to which the Port Identifier refers. If the Link Address is greater than one byte it shall 
be padded so that the length of the entire port segment is an even number of bytes. The pad 
byte shall be set to zero and shall not be included in the Link Address Size. With respect to the 
specification of a DeviceNet Port, the Link Address shall indicate the target DeviceNet MAC 
ID and be specified in a single byte whose value is 0 — 63 (the valid range of DeviceNet MAC 
Ids). 


The Extended Port Identifier format of the Port Segment shall only be used when there are 


more than 14 network ports possible on the connecting device. The Port Segment shall always 
be represented in the smallest Port Segment format possible with respect to the optional fields. 


Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Appendix C: Data Management 


Examples of Port Segments are presented below. 
Segment Type = Port Segment. Port Number = 2, Link Address 
= 6 


[OF][12][00][01] Segment Type = Port Segment. Port Identifier is 15 indicating the 
Port Number is specified in the next 16 bit field [12][00] (18 


decimal). Link Address = 1. 


[15][OF][31][33][30][2E] Segment Type = Port Segment. Multi-Byte address for TCP Port 

5, Link Address 130.151.137.105 (IP Address). The address is 
BHP SIP SEEN H3=l defined as a character array, length of 15 bytes. The last byte in 
(37][2E][31][30][35][00] the segment is a pad byte. 


C-1.4.2 LOGICAL SEGMENT 


The logical segment selects a particular object address within a device (for example, Object 
Class, Object Instance, and Object Attribute). When the logical segment is included within a 
Packed Path, the Logical Value shall be appended to the segment type byte with no pad in 
between. When the logical segment is included within a Padded Path, the 16-bit and 32-bit 
logical formats shall have a pad inserted between the segment type byte and the Logical Value 
(the 8-bit format is identical to the Packed Path). The pad byte shall be set to zero. 


Segment Format Bits 


Segment Type Logical Type Logical Format Logical Value 
0; Of; 1 
Logical Type Logical Format 
ClassID 0 O 0 0 0 8-bit logical address 
InstanceID 9 QO 1 (0) 16-bit logical address 
MemberID 0 1 O 1 0O 32-bit logical address 
Connection Point 9 I! 1 1 Reserved for future use 
AttributeID 1 0 0 
Special* 1 O 1 


Service ID* 1 1 0O 


— 
= 


Reserved for future use 1 
*The Special and Service ID Logical Types do not use the logical addressing definition for the Logical Format. 
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The 8-bit logical address format is allowed for use with all Logical Types. 


The 16-bit logical address format is only allowed for use with Logical Types Class ID, 
Instance ID, Member ID, and Connection Point. 


The 32-bit logical address format is not allowed (reserved for future use). 


The Connection Point Logical Type provides additional addressing capabilities beyond the 
standard Class ID/Instance ID/Attribute ID/Member ID Object Address. Object Classes shall 
define when and how this addressing component is utilized. 


The Service ID Logical Type has the following definition for the Logical Format: 


00 8-Bit Service ID Segment (0x38) 
01 Reserved for future use (0x39) 
10 Reserved for future use (0x3A) 
11 Reserved for future use (0x3B) 


The Special Logical Type has the following definition for the Logical Format: 


00 Electronic Key Segment (0x34) 
01 Reserved for future use (0x35) 
10 Reserved for future use (0x36) 
1 1 Reserved for future use (0x37) 


The Electronic Key segment shall be used to verify/identify a device. Possible uses include 
verification during connection establishment and identification within an EDS file. This 


segment has the format as shown in the table below. 


Electronic Key Segment Format 


Field Name Data Type Semantics 
Segment Type USINT A value of 0x34 indicates a Logical Electronic 
Key segment 
Key Format USINT 0 —3 = Reserved 


4 = see Key Format Table 
5 — 255 = Reserved 


Key Data Array of octet Depends on key format used 
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Key Format Table 


Format Field Name Data Semantics 
Value Type 
4 Vendor ID UINT Vendor ID 
Device Type UINT Device Type 
Product Code UINT Product Code 
Major Revision / BYTE Bits 0 — 6 = Major Revision 
Compatibility Bit 7 = Compatibility (If clear then any non-zero 


Vendor ID, Device Type, Product Code, Major 
Revision, and Minor Revision shall match. If set, 
then any key may be accepted which a device can 
emulate.) 


Minor Revision USINT | Minor Revision 


An encoding that specifies Class #5, Instance #2, and Attribute ID #1 is illustrated below (Note 
that the packed and padded representations are the same): 


Segment Type = Logical Segment 
Segment Format: Logical Type = Class 
A Logical Format = 8 bits 


Segment Type = Logical Segment 
Segment Format: Logical Type = Instance 
N Logical Format = 8 bits 


Segment Type = Logical Segment 
Segment Format: Logical Type = Attribute ID 
N Logical Format = 8 bits 


Class #5 Instance #2 Attribute ID #1 


The same example is presented below, except that the Class information is specified in a 16 bit 
field. Figure C-1.2 shows a packed representation and Figure C-1.3 shows padded. 
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Figure C-1.2 Packed EPATH with 16 bit Class 


Segment Type = Logical Segment 
Segment Format: Logical Type = Class 
A Logical Format = 16 bits 


Segment Type = Logical Segment 
Segment Format: Logical Type = Instance 
N Logical Format = 8 bits 


Segment Type = Logical Segment 
Segment Format: Logical Type = Attribute ID 


N Logical Format = 8 bits 
pa fs fe]» fel a] o | 
v Vv v 
v Instance #2 Attribute ID #1 


Class #5 


Figure C-1.3 Padded EPATH with 16 bit Class 


21 


Pad inserted here for padded representation 


C-1.4.3 NETWORK SEGMENT 


The network segment shall be used to specify network parameters that may be required by a 
node to transmit a message across a network. The network segment shall immediately precede 
the port segment of the device to which it applies. In other words, the network segment shall 


be the first item in the path that the device receives. 


Network Segment Sub-Type Network 
Segment Type Segment Data 
o! 1/0 Variable length 


00000 Reserved for future use 
00001 Schedule Segment 
00010 Fixed Tag Segment 
00011 Production Inhibit Time 
00100 Reserved for future use 
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C-1.4.3.1 


C-1.4.3.2 


C-1.4.3.3 


Release 1.0 


SCHEDULE NETWORK SEGMENT 


The Schedule network segment is defined by the ControlNet International specification (Part 4, 
clause 3.2.2.4). 


FIXED TAG NETWORK SEGMENT 


The Fixed Tag network segment is defined by the ControlNet International specification (Part 
4, clause 3.2.2.4). 


PRODUCTION INHIBIT TIME NETWORK SEGMENT 


The production inhibit time network segment shall specify the minimum time, in milliseconds, 
between successive transmissions of connected data for the specified connection. For example, 
if a production inhibit time of 10 milliseconds is specified, new data shall be sent no sooner 
than 10 milliseconds after the previous data. The network segment data field shall be a single 
USINT (8 bits) allowing for a range of | — 255 milliseconds. A value of zero shall indicate no 
production inhibit time. When this segment does not exist during establishment of a 
connection a default value of one-fourth the RPI shall be used. 


The RPI shall be larger than the production inhibit time. If the RPI is smaller than the 


production inhibit time, the Forward_Open_reply shall be returned with error (status 0x01, 
extended status 0x111). 
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C-1.4.4 SYMBOLIC SEGMENT 


The symbolic segment contains an International String symbol which must be interpreted by 
the device. 


Segment Format Bits 


Segment Type Symbol Size in Bytes 


Size 1- 31: Length of ASCII symbol in bytes 


Size 0: Extended string. The next byte 
is the extended string format 


Extended string format byte: 
7 6 5 4 3 2 #1 =O 


Nee eee No, oe” 


Format Size 

001 Number of Double-byte characters (1-31) 
010 Number of Triple-byte characters (1-31) 
110 


Numeric symbol type 
6 = USINT (0-255) 
7 = UINT (0-65535) 
8 = UDINT (0-4,294,967,295) 
All other values reserved 


Character Symbols can contain a maximum of 31 characters. 
Numeric Symbols can be 8, 16, or 32 bits. 


For example (values are hexadecimal): 
Symbolic Segment Notes 


[65][LS101] ASCII Symbol. This could refer to a bit in a data structure 
(67][Line_23] ASCII Symbol. This could refer to a controller in a slot 
(68][Wire_off] ASCII Symbol. This could refer to a bit in a diagnostic structure 

(60][22][1234][2345] | Japanese symbol 
[60][C7][1234] 16 bit Numeric Symbol 
[60][C8][12345678] | 32 bit Numeric Symbol 
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C-1.4.5 DATA SEGMENT 


The data segment provides a mechanism for delivering data to an application. This may occur 
during connection establishment, or at any other time as defined by the application. 


Data Segment Segment Sub-Type Data Segment 
Type Data 
1); 0} 0 Variable length 


00000 Simple Data Segment (0x80) 


00001 Reserved for future use 
thru 
10000 
10001 ANSI Extended Symbol Segment (0x91) 
10010 Reserved for future use 


thru 
11111 


C-1.4.5.1 SIMPLE DATA SEGMENT 


The Simple data segment contains data values such as parameters for the target application. 
The size of the data segment is specified in number of 16 bit words and depends on the 
application. This byte value immediately follows the segment type. The data values follow the 
length byte. The data segment can be any number of 16 bit words up to 255. An encoding can 
contain more than one data segment if required. 


The following table provides examples of data segments: 


Encoding Notes 


[80][07] [0100] [0200] [0300] [0400] [0500] 
[0600] [0700] 


Seven words of data in a 
data segment 


[21] [0500] [24] [09] [80][04] [0100] [0200] 
[0300] [0400] 


Logical segments for 
Class 5, Instance 9, then 
four words of data in a 
data segment 


The data can be configuration information for the object, additional parameters necessary for 
the object, or any other set of object specific information. 
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C-1.4.5.2, ANSI EXTENDED SYMBOL SEGMENT 


The segment type of ANSI extended symbol segment shall be 0x91. The byte following the 
segment type (second byte) shall represent the number of characters (8-bit) in the symbol 
(symbol size). The variable length symbol shall follow the symbol size and shall end with a 
pad byte of zero if the size is of odd length. The symbol size shall not count the pad byte if it is 
included. 


The following table provides examples of extended symbol segments: 


Encoding Notes 


[91][06] [73] [74] [61] [72] [74] [31] Six bytes of data in the symbol 
“start 1? 


[91] [07] [73] [74] [61][72] [74] [65] [72] [00] | Seven bytes of data in the symbol 


‘starter’ (plus a null pad) 


C-1.5 Segment Definition Hierarchy 
The definition of any rules related to the use of segments is defined within the Object Class 
and/or Device Profile. The following are examples of valid recommended hierarchies. The 
depth within the hierarchy need only proceed to the degree required by its application. 
Class ID, 
Class ID, Instance ID 
Class ID, Instance ID, Attribute ID 


Class ID, Instance ID, Attribute ID, Member ID 


Class ID, Connection Point 
Class ID, Connection Point, Member ID 
Class ID, Instance ID, Connection Point 
Class ID, Instance ID, Connection Point, Member ID 
The following example demonstrates encoding for two path attributes: the 


produced_connection_path and consumed_connection_path attributes of the Connection 
Object. 
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Figure C-1.4. Example Encoding for Connection Object Paths 


Connection Object Class (ID 5) Assembly Object Class (ID 4) 


Connection Instance ID 2 Assembly Instance ID 1 


connection_ i Class ID 4, = 
path_length : InstanceID1, | MemberList | | 


i AttributeID3 : 
produced_ i i Data 
connection ? i (Attribute ID 3) 


path 


consumed_ 


connection_ Assembly Instance ID 6 


path_ length i ClassID4, 

4 : Instance ID 6, Num Members |_| 
consume i : H : 
connection_ i Member List 2— 11 


path : Data 
(Attribute ID 3) 
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C-2 


C-2.1 


C-2.1.1 


DATA TYPE SPECIFICATION 


This section describes the data type specification syntaxes, data type value ranges, and 
operations that can be performed on the defined data types. The specification of a data type 
comprises: 


e the range of values that variables of the type may take on, and 
e the operations performed on these variables 


This CIP standard specifies elementary and derived data types corresponding to the notation of 
IEC 1131-3. In addition, since function blocks as defined in IEC 1131-3 have both an 
associated data structure and a set of defined standard operations, these elements are also 
specified as data types in this CIP standard. 


Data Type Values 
Data is made up of elementary (primitive) data types. These elementary data types are used to 
construct derived (constructed) data types. 


Elementary Data Types 


The elementary data types and the values (range) of variables of each type are given in Table 
C-2.1 and its associated notes. This table specifies the values of certain parameters which are 
identified as “implementation—dependent” in Table 10.1 of subclause 2.3.1 in IEC 1131-3. The 
implementation—dependent parameters defined in this CIP Common specification can be found 
in Table C-3.4. 


Table C-2.1. Elementary Data Types 


Keyword Description Minimum Maximum 
BOOL NOTE | 
SINT 127 
INT 32767 


DINT Double Integer 931.4 
LINT Long Integer 763_4 


USINT Unsigned Short Integer Saat 
UINT Unsigned Integer Oo =—s«Y 655351 


UDINT Unsigned Double Integer Oo 932.4 
ULINT Unsigned Long Integer Oo 764_4 


REAL NOTE 2 
LREAL NOTE 3 
ITIME NOTE 12 
TIME NOTE 4 
FTIME NOTE 5,6 
LTIME NOTE 6,7 
DATE NOTE 8 
TIME_OF_DAY or TOD NOTE 9 
DATE_AND_TIME or DT NOTE 10 
STRING 
STRING2 NOTE 6 
STRINGN NOTE 6 
SHORT_STRING character string (1 byte per character, 1 NOTE 6 


byte length indicator) 
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Range 
Keyword Description Minimum Maximum 


BYTE bit string - 8 bits NOTE 11 


WORD bit string - 16-bits NOTE 11 

DWORD bit string - 32-bits NOTE 11 

LWORD bit string - 64-bits NOTE 11 

EPATH CIP path segments NOTE 13 

ENGUNITS ENGINEERING UNITS NOTE 14 

1 The possible values of variables of type BOOL 0 and 1, corresponding to the keywords FALSE and 
TRUE, respectively. 

2 The range of values for variables of type REAL are defined in IEEE 754 for the basic single 
floating-point format. 

3 The range of values for variables of type LREAL are defined in IEEE 754 for the basic double 
floating-point format. 

4 The range of values for variables of type TIME is the same as for variables of type DINT, representing 
the time duration in milliseconds, i.e., a range of T#-24d20h3 1m23.648s to T#24d20h3 1m23.647s. 

5 The range of values for variables of type FTIME is the same as for variables of type DINT, representing 
the time duration in microseconds, 1.e., a range of T#-35m47.483648s to T#35m47.483547s. 

This is a CIP standard extension to IEC 1131-3. 

The range of values for variables of type LTIME is the same as for variables of type LINT, representing 
the time duration in microseconds, i.e., a range of T#-106751991d4h0m54.775808s to 
T#106751991d4h0m54.775807s. 

8 The range of values for variables of type DATE is from D#1972-01-01, the start of the Coordinated 
Universal Time (UTC) era, to D#215 1-06-06 (a total range of 65536 days). 

9 The range of values for variables of type TIME OF DAY is from TOD#00:00:00.000 to 
TOD#23:59:59.999 to a resolution of 1 millisecond. 

10 The range of values for variables of type DATE _AND_TIME is from DT#1972-01-01-00:00:00.000 to 
DT#2151-06-06-23:59:59.999. 

11 Values of bit string data types is in the range 2#by_ by_2...bb) bg, where N is the number of bits in the 
bit string, byy_1 is the “most significant bit”, and bg is the “least significant bit”. The value of the j-th 
bit bj is represented as 0 or 1, corresponding to the Boolean value FALSE or TRUE, respectively. 

12 The range of values for variables of type ITIME is the same as for variables of type INT, representing 
the time duration in milliseconds, i.e., a range of T#-32s768ms to T#32s767ms. 

13° For complete information on the EPATH data type, refer to Appendix C: Abstract Syntax Encoding for 
Segment Types. 

14 


The range of values for variables of type ENGUNIT is the same as for variables uint, representing the 
values enumerated in Appendix D of the CIP specification. 


Character String Data Types 


The declaration of a variable of type STRING, STRING2, or STRINGN is equivalent to 
declaring a structured data type for the variable which allocates a UINT variable containing the 
current size of the string in characters and an array of declared character size elements. 
STRING declares 8-bit octet elements. STRING2 declares 16-bit octet elements. STRINGN 
declares N*8-bit octets. STRINGN includes a UINT variable which declares the character size. 


The declaration of a variable of type SHORT_STRING is equivalent to declaring a structured 
data type for the variable which allocates a USINT variable containing the current size of the 
string in characters and an array of 8-bit octet elements. 


SHORT_STRING, STRING2 and STRINGN are extensions to IEC 1131-3. 
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C-2.1.2 


Structured Bit String Types 


Structured bit string types are a CIP extension of the derived data type mechanisms specified in 
subclause 2.2.3 of IEC 1131-3. These data types are based on the IEC standard bit string types 
(ANY_BIT = BYTE, WORD, DWORD, or LWORD). 


DERIVED DATA TYPES 
The derived data types specified by CIP are: 


directly derived 
enumerated 
subrange 
structured 

array 


These data types are defined in subclauses 1.3 and 2.3.3 of IEC 1131-3. The means of 
specifying these data types and their default initial values is defined in subclauses 2.3.3.1 and 
2.3.3.2 of IEC 1131-3. The usage of variables of these data types is defined in subclause 2.3.3.3 
of IEC 1131-3. 
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C-3 IEC 1131-3 COMPLIANCE 


Subclause 1.5.1 of IEC 1131-3 defines the requirements which are met by programmable 
controller systems claiming compliance to the language standard. This provides the data 
type-related information to be included in the documentation of CIP functional units which 
support the data types defined in this CIP standard. Subsets or extensions of this documentation 
are provided as appropriate to the specific compliant functional unit. 


This section provides information with respect to only the data types and associated operations 
defined in this CIP standard. For full compliance with IEC 1131-3, documentation of the 
additional language elements supported by the functional unit must be provided as prescribed 
in subclause 1.5.1 of IEC 1131-3. 


Included in this section are the following: 


e Compliance Statement 

e Implementation-Dependent Parameters 
e Error Conditions 

e Language Extensions 

e Formal Syntax 


C-3.1 Compliance Statement 


This system complies with the requirements of IEC 1131-3 for the following language features: 


Table C-3.1. Common Elements 


Table/ Feature description 
Feature 

10/1 BOOL data type 

10/2 SINT data type 

10/3 INT data type 

10/4 DINT data type 

10/5 LINT data type 

10/6 USINT data type 

10/7 UINT data type 

10/8 UDINT data type 

10/9 ULINT data type 

10/10 REAL data type 

10/11 LREAL data type 

10/12 TIME data type 

10/13 DATE data type 

10/14 TIME OF DAY or TOD data type 

10/15 DATE _AND_TIME or DT data type 

10/16 STRING data type 

10/17 BYTE data type 

10/18 WORD data type 

10/19 DWORD data type 

10/20 LWORD data type 

12/1 Directly derived data types 

12/2 Enumerated data types 

12/3 Subrange data types 
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Table/ 
Feature 

12/4 
12/5 
13 
Subclause 
2.5.1.3 
22/1 
22/2 
22/3 
22/4 
23/1-11 


24/ 
12n-18n 
24/ 
12s-15s, 
17s,18s 
25/1-4 
26/ 

5s-8s 

26/ 

5s-7s 
27/1-4 
28/5n-10n 
28/5s-10s 
29/ 

1-9 

30/ 

1-14 


31/1-4 
32 


33/8a,8b,9a, 


37/1,2a, 
3a, 4 


55/1-17 


Table C-3.2. 


Table/ 
Feature 


55/ 
1-17 


56/2 


Feature description 


Array data types 
Structured data types 
Standard default initial values 
User-declared functions 
(no table entry) 
Type conversions (see Table J.4) 
TRUNC function 
BCD_TO ** functions 
* TO BCD functions 
Standard functions of one numeric variable: 
ABS, SQRT, LN, LOG, EXP, SIN, COS, TAN, ASIN, ACOS, ATAN 
Standard named arithmetic functions: 
ADD, MUL, SUB, DIV, MOD, EXPT, MOVE 
Standard symbolic arithmetic functions: 
+,*-,/, 
eR a 
Standard bit string functions: SHL, SHR, ROR, ROL 
Standard named bitwise Boolean functions: 
AND, OR, XOR, NOT 
Standard symbolic bitwise Boolean functions: 
&, >=1, =2k+1 
Standard selection functions: SEL, MAX, MIN, LIMIT, MUX 
Standard named comparison functions: GT, GE, EQ, LE, LT, NE 
Standard symbolic comparison functions: >, >=, =, <=, <, <> 
Standard character string functions: LEN, LEFT, RIGHT, MID, CONCAT, 
INSERT, DELETE, REPLACE, FIND 
Standard functions of time data types: 
ADD, SUB, MUL, DIV, CONCAT, 
DATE AND TIME TO TIME OF DAY, 
TIME OF DAY TO DATE AND TIME 
NOTE- Table 30 of IEC 1131-3 limits the data types to 
which these operations apply. 
Standard functions of enumerated data types: SEL, MUX, EQ, NE 
Standard access mechanisms to function block I/O parameters 


User-defined function blocks per subclause 2.5.2.2, 
with graphical or textual rising or falling edge input options 


Standard bistable function blocks: SR, RS, SEMA 
Standard edge detection function blocks: R EDGE, F_ EDGE 
Standard counter function blocks: CTU, CTD, CTUD 


Standard timer function blocks: TP, TON, TOF, RTC 


Standard operators: (), function evaluation, **,—-, NOT, 
*, /, MOD, +,-, < >, <=, >=, =, <>, & AND, XOR, OR 


ST Language Elements 


Feature description 


Standard operators: (), function evaluation, **,—-, NOT, 
S /, MOD, he, <, >; S53 a => L, &, AND, XOR, OR 


Function block invocation and output usage 
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Table C-3.3. Type conversion operations 


Refer to the notes following this table. 


Operation 
ANY _BIT_TO_ANY BIT 
ANY_BIT_TO_ANY_ INT 


ANY_BIT_TO_BOOL 


ANY_BIT_TO_STRING 
ANY_DATE_TO_STRING 
ANY_INT_TO_BOOL 


ANY _NUM_TO_ANY_INT 


Y_NUM_TO_ANY REAL 
Y_NUM_TO DATE 
ANY_NUM_TO_STRING 
Y_NUM_TO_TIME 
Y NUM TO TOD 


ANY_REAL_TO_BOOL 


BOOL_TO_ANY_BIT 
BOOL TO ANY INT 


BOOL_TO_ANY_REAL 


BOOL_TO STRING 


DATE_TO_ANY NUM 


STRING TO ANY 
TIME_TO_ANY_NUM 


TOD_TO_ANY_NUM 


Result 
(NOTE 4) 
UT min + Sby2k (NOTE 5) 

FALSE if IN=0 

TRUE otherwise 

(NOTE 6) 

(NOTE 7) 

FALSE if IN=0 

TRUE otherwise 

IN (NOTE 8) 


i 


Z 
ie) 
ua) 
tH 
we 


(NOTE 10) 
(NOTE 11) 
(NOTE 12) 


(NOTE 13) 


FALSE if IN = 0.0 
TRUE otherwise 


0 if IN = FALSE 
1 if IN= TRUE 


0.0 if IN= FALSE 
1.0 if IN= TRUE 


*FALSE’ if IN = FALSE 
>TRUE’ if IN= TRUE 


(NOTE 14) 
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Error conditions 


None 
Result > OUT pax 


None 


None 
None 


None 


(IN > OUT pax) or 


(IN < OUT nin) 


None 


None 


None 


None 


Result > OUT pax 


(NOTE 15) 
Result > OUT pax 


Result > OUT pax 


1 Use of the generic data types ANY NUM, ANY_ REAL, ANY_ INT, and ANY BIT defined in 
subclause 2.3.2 of IEC 1131-3 is intended to imply a family of conversions. For instance, the 
conversion BOOL_TO_ANY REAL is intended to imply BOOL_TO_REAL and 


BOOL TO LREAL. 


3 OUT pin and OUT max 


conversion function, as defined in Table J.1 


IN refers to the value of the input variable of the type conversion function. 


refer to the minimum and maximum values of the output data type of the 
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Operation Error conditions 


In conversions of bit string types, if the number of bits in the input variable IN is less than the 
number of the bits in the output variable OUT, the bits of the input is copied to the corresponding 
least significant bits of the result and the remainder of the result is zero-filled. If the number of bits 
of IN is greater than the number of bits of OUT, the least significant bits of IN is copied to the 
corresponding bits of the result. For instance, 

BYTE_TO_WORD(16#FF) = 16#00FF 

and 
WORD TO BYTE(16#0FFO) = 16#FO 


Bit numbering in this expression is as specified in Note 11 of Table J.1 


The result of conversion of a bit string variable to type STRING consists of a string containing the 
base 16 literal representation of the variable value, as defined in subclause 2.2.1 of IEC 1131-3, in 
characters taken from the ISO 646 character set. 


The result of conversion of a date and/or time of day variable to type STRING consists of a string 
containing the literal representation of the variable value, as defined in subclause 2.2.1 of IEC 
1131-3, in characters taken from the ISO 646 character set. 


Conversion of REAL and LREAL to integer types is accomplished by rounding as specified in 
subclause 5.4 of IEEE 754. 


Rounding errors may occur if the number of significant bits in the input variable is larger than the 
number of significant bits in the output floating-point representation. Also, range errors of the type 
noted for ANY NUM_TO ANY INT may occur in LREAL TO REAL. 


10 Conversion of a variable of a numeric type to DATE has the same result as conversion of the 


variable to UINT, with the result being interpreted as the number of days since 1972-01-01. 


11 Conversion of a variable of a numeric type to type STRING consists of a string containing the literal 


representation of the variable value, as defined in subclause 2.2.1 of IEC 1131-3, in characters taken 
from the ISO 646 character set. 


12 Conversion of a variable of a numeric type to TIME has the same result as conversion of the variable 


to DINT, with the result being interpreted as a duration in milliseconds. 


13° Conversion of a variable of a numeric type to TOD has the same result as conversion of the variable 


to UDINT, with the result being interpreted as a time since midnight in milliseconds. 


14 Conversion of a variable of type DATE to a numerical type is the same as the conversion of a 


variable of type UINT to the corresponding numerical type, with the result being the numerical 
equivalent of the days since 1972-01-01. 


15 Tt is an error if the STRING data to be converted is not in the format for external representation of 


the output data type as specified in subclause 2.2 of IEC 1131-3, or if the result of the conversion is 
outside the range {OUT. OUT 


min* max}: 


16 Conversion of a variable of type TIME to a numerical type is the same as the conversion of a 
variable of type DINT to the corresponding numerical type, with the result being the numerical 
equivalent of the corresponding time interval expressed in milliseconds. 


17 Conversion of a variable of type TOD (TIME OF DAY) to a numerical type is the same as the 
conversion of a variable of type UDINT to the corresponding numerical type, with the result being 
the numerical equivalent of the time since midnight expressed in milliseconds. 


C-3.2 Implementation-Dependent Parameters 


Table C-3.4 lists the values of implementation-dependent parameters from Table D.1 of IEC 
1131-3. that are defined in this CIP standard. Values of other implementation-dependent 
parameters are defined in other CIP standards or in the specifications of individual functional 
units as appropriate. 
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Table C-3.4. Values of implementation—dependent parameters 


Clause Parameter Value 
of IEC 
1131-3 
2.2.3.1 Same as LINT in microseconds 


2.3.1 Same as DINT in milliseconds 
Precision of representation of seconds in types 1 millisecond 
2.3.3.1 Maximum number of enumerated values 256 


2.3.3.2 Default maximum length of STRING variables 256 
Maximum allowed length of STRING variables 65536 


2.4.1.2 Maximum number of subscripts 8 


Maximum nanbor oes ofan (8 
2515.1 As defined in Table J.4 
25:11:52 As defined in IEEE 754 


C-3.3 Language Extensions 


The extensions to IEC 1131-3 defined in this CIP standard are listed in Table C-3.5 When these 
extensions are used in a particular CIP compliant functional unit, the subclause references in 
this table are replaced by references to the descriptions of the corresponding extensions in the 
functional unit’s documentation. 


Table C-3.5. CIP standard extensions to IEC 1131-3 


Subclause Description 


ITIME data type 

FTIME data type 

LTIME data type 
STRING? data type 
STRINGN data type 
SHORT_STRING data type 
EPATH data type 
ENGUNIT data type 


Structured bit string types 
Operations on STRING2 variables 
Numbered bit string access 


2.1.1 


2.1.4 
2.2 
2.2.4.1 
2.2.4.2 


Structured bit string access 
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C-4 


C-4.1 


C-24 


ABSTRACT SYNTAX SPECIFICATION 


The lower layers of open system architectures are concerned with the transport of user data 
among distributed functional units. In these layers, the user data can be regarded simply as a 
sequence of octets. However, application layer entities may manipulate the values of quite 
complex data types. To achieve independence between the application layer and lower layers, 
data types are specified in an abstract syntax notation. 


Supplementing the abstract syntax with one or more algorithms (called encoding rules) 
determines the values of the lower layer octets which carry the application layer values. The 
combination of the abstract syntax with a single set of transfer rules produces a specific transfer 
syntax. 


Important: Users of this CIP standard should read and understand ISO 8824/8825, IEC 
1131-3, and J.4 Refer to these documents when reading and applying this standard. 


The data type definitions provided in this CIP standard are written in Abstract Syntax Notation 
One (ASN.1), as defined in ISO 8824. These type definitions are part of the ASN.1 module 
“CIPDataTypes.” The beginning ASN.1 statement indicating that these definitions are in this 
module is: 


CIPDataTypes DEFINITIONS ::= BEGIN 


and the closing ASN.1 statement is the keyword “END”. 


The abstract definitions that follow comprise the set of CIP Data Types. In addition, provision 
is made to extend or derive new data types based on existing defined types, and to include 
those in a “type dictionary.” 


CIP Data Specification 


The notation [typeld] for directly derived, enumerated, subrange and structured bit string data 
means that the tag is to be taken from the “type” field in the corresponding 
VariableDictionaryEntry. 


CIPData ::= CHOICE{ElementaryData, DerivedData} 


ElementaryData::= CHOICE{ 
BOOL, 
FixedLengthInteger, 
FixedLengthReal, 
AnyTime, 
AnyDate, 
AnyString, 
FixedLengthBitString, 
EPATH 
ENGUNIT } 
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DerivedData::= CHOICE { 

DirectlyDerivedData, 

EnumeratedData, 

SubrangeData, 

StructuredBitStringData, 

ARRAY, 

STRUCT, 

FunctionBlockData} 
DirectlyDerivedData ::= [typeId] CIPData 
EnumeratedData ::= [typeId] USINT 
SubrangeData ::= [typeId] FixedLengthInteger 
StructuredBitStringData ::= [typeId] FixedLengthBitString 
FixedLengthInteger ::= CHOICE {SignedInteger, UnsignedInteger} 
SignedInteger ::= CHOICE {SINT, INT, DINT, LINT} 
UnsignedInteger = CHOICE {USINT, UINT, UDINT, ULINT} 
FixedLengthReal = CHOICE {REAL, LREAL} 
AnyTime ::= CHOICE {ITIME,TIME, FTIME, LTIME} 
AnyDate ::= CHOICE {DATE, TIME_OF_DAY, DATE_AND_TIME} 
AnyString ::= CHOICE {STRING, STRING2} 
FixedLengthBitString::= CHOICE {BYTE, WORD, DWORD, LWORD} 
BOOL = [PRIVATE 1] IMPLICIT BOOLEAN 
SINT = [PRIVATE 2] IMPLICIT OCTET STRING-- 1 octet 
INT ::= [PRIVATE 3] IMPLICIT OCTET STRING-- 2 octets 
DINT = [PRIVATE 4] IMPLICIT OCTET STRING-- 4 octets 
LINT = [PRIVATE 5] IMPLICIT OCTET STRING-- 8 octets 
USINT ::= [PRIVATE 6] IMPLICIT OCTET STRING-- 1 octet 
UINT ::= [PRIVATE 7] IMPLICIT OCTET STRING-- 2 octets 
UDINT ::= [PRIVATE 8] IMPLICIT OCTET STRING-- 4 octets 
ULINT ::= [PRIVATE 9] IMPLICIT OCTET STRING-- 8 octets 
REAL ::= [PRIVATE 10] IMPLICIT OCTET STRING-- 4 octets 
LREAL ::= [PRIVATE 11] IMPLICIT OCTET STRING-- 8 octets 
STIME ::= [PRIVATE 12] IMPLICIT DINT 
DATE ::= [PRIVATE 13] IMPLICIT UINT 


TIME_OF_DAY 


[PRIVATE 14] IMPLICIT UDINT 
DATE_AND_TIME [PRIVATE 15] IMPLICIT SEQUENCE { 
time_of_day UDINT, date UINT } 


STRING ::= [PRIVATE 16] IMPLICIT SEQUENCE { 
charcount UINT, 
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stringcontents OCTET S 


BYTE [PRIVATE 17] 


WORD [PRIVATE 18] 


DWORD [PRIVATE 19] 


LWORD [PRIVATE 20] 


[PRIVATE 21] 
UINT, 


STRING2 
charcount 
string2contents 


FTIME 


[PRIVATE 22] 


LTIME 


[PRIVATE 23] 


ITIME I 


[PRIVATE 24] 


STRINGN [PRIVATE 25] 
charsize UINT, 
charcount UINT, 
stringNcontents 

SHORT_STRING = 

charcount 

stringcontents 


USINT, 


TIME [PRIVATE 27] 


EPATH [PRIVATE 28] 


ENGUNIT [PRIVATE 29] 


ARRAY 


STRUCT 


FunctionBlockData 
inputs 
outputs 
controliInputs 
controlOutputs 


[0] 
[1] 
[2] 
[3] 


C-4.2 


IMPLICIT OCTET 
IMPLICIT OCTET 


IMPLICIT OCTET 


OCTET STRING} 


OCTET STRING} 
[PRIVATE 26] 


OCTET STRING} 


IMPLICIT OCTET STRING 


SEQUENCE OF CIPData 


SEQUENCE OF CIPData -- 
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octet per character 
STRING-- 1 octet 


TRING} -- one 


STRING-- 2 octets 
STRING-- 4 octets 
IMPLICIT OCTET STRING-- 8 octets 
IMPLICIT SEQUENCE { 


2 octets/ character 


IMPLICIT DINT 


IMPLICIT LINT 


MPLICIT INT 


IMPLICIT SEQUENCE { 


N octets/ character 


IMPLICIT SEQUENCE { 


-- one octet per character 


IMPLICIT DINT 


—- Appendix C 


IMPLICIT OCTET STRING -- Appendix D 


All of same base type 


May be different types 


SET { 


STRUCT OPTIONAL, 
STRUCT OPTIONAL, 
STRUCT OPTIONAL, 
STRUCT OPTIONAL} 


IMPLICIT 
IMPLICIT 
IMPLICIT 
IMPLICIT 


Data Type Specification/Dictionaries 


The definition of a CIP object may include text that defines attributes. Attributes are assigned a 
Data Type in an object definition. The Data Type may be one of those defined in this appendix 
or may be an object specific extension to this appendix. The following definition provides a 
Type Specification for CIPData and provides a structure for extending or deriving new data 


types based on existing defined types. 


Dictionary 


VariableDictionary 
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CHOICE {VariableDictionary, 


Open DeviceNet Vendor Assoc. & ControlNet International 
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SEQUENCE OF VariableDictionaryEntry 
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VariableDictionaryEntry ::= SEQUENCE { 

name AnyString, 

id FixedLengthInteger, 

type TypelID, 

ranges SEQUENCE OF Subrange,-- for arrays 

accessPrivilege BOOL {READ_ONLY (0), READ WRITE (1) } 
TypeID ::= OCTET STRING -- ASN.1 encoded tag value of the 

-—- DataTypeSpecification module 

Subrange ::= SEQUENCE { 


minValue FixedLengthInteger, 
maxValue FixedLengthInteger} 


TypeDictionary 
TypeDictionaryEnt 
name 
type 
spec 
DataTypeSpecification ::= 
alt [PRIVATE 
bool [PRIVATE 
sint [PRIVATE 
int [PRIVATE 
dint [PRIVATE 
lint [PRIVATE 
usint [PRIVATE 
uint [PRIVATE 
udint [PRIVATE 
ulint [PRIVATE 
real [PRIVATE 
lreal [PRIVATE 
stime [PRIVATE 
date [PRIVATE 
tod [PRIVATE 
dat [PRIVATE 
strl [PRIVATE 
byte [PRIVATE 
word [PRIVATE 
dword [PRIVATE 
lword [PRIVATE 
str2 [PRIVATE 
ftime [PRIVATE 
ltime [PRIVATE 
itime [PRIVATE 
strN [PRIVATE 
shstr [PRIVATE 
time [PRIVATE 
epath [PRIVATE 


engunit [PRIVATE 


ry 


AnyString, 
TypelID, 
DataTypeSpecification} 


CHOICE { 


0] 
1] 
2] 
3] 
4] 
5] 
6] 
7] 
8] 
9] 
10] 
11] 
12] 
13] 
14] 
£5) 
16] 
17] 
18] 
19] 
20] 
21] 
22] 
23] 
24] 
25] 
26] 
2] 
28] 
29] 


HHHHHHHHHHHHHHHHRHHHRHRRARRHRaeaaa a 


:= SEQUENCE { 


MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 
MPLICIT 


::= SEQUENCE OF TypeDictionaryEntry 


AlternateTypeSpec, 

NULL, == BOOL 

NULL, oe SINT 

NULL, -- INT 

NULL, a DINT 

NULL, a LINT 

NULL, == USINT 

NULL, ng UINT 

NULL, ag UDINT 

NULL, a ULINT 

NULL, == REAL 

NULL, == LREAL 

NULL, -- STIME 

NULL, ae DATE 

NULL, a TIME_OF_DAY 
NULL, =s DATE_AND_TIME 
NULL, ae STRING 
NULL, ag BYTE 

NULL, a7 WORD 

NULL, a DWORD 

NULL, == LWORD 

NULL, -- STRING2 
NULL, cae FTIME 

NULL, == LTIME 

NULL, == ITIME 

NULL, ae STRINGN 
NULL, == SHORT_STRING 
NULL, se TIME 

NULL, -- EPATH 

NULL, = ENGUNIT 


Release 1.0 Open DeviceNet Vendor Assoc. & ControlNet International 


C-27 


Appendix C: Data Management Volume 1: CIP Common Specification 


C-28 


constructedData CHOICE { 


abbrvStruc [0] IMPLICIT AbbreviatedStrucTypeSpec, 
abbrvArr [1] IMPLICIT AbbreviatedArrayTypeSpec, 
frmlStruc [2] IMPLICIT FormalStrucTypeSpec, 
frmlArr [3] IMPLICIT FormalArrayTypeSpec, 
expBitStr [4] IMPLICIT ExpandedFixedLenBitStrTypeSpec, 
expStrl [5] IMPLICIT ExpandedStringTypeSpec, 
expStr2 [6] IMPLICIT ExpandedString2TypeSpec} 
} 
AbbreviatedStrucTypeSpec ::= UINT 
AbbreviatedArrayTypeSpec ::= DataTypeSpecification 
FormalStrucTypeSpec = SEQUENCE OF DataTypeSpecification 
FormalArrayTypeSpec ::= SEQUENCE { 
lowBound [0] IMPLICIT FixedLengthInteger, -- Array Lower Bound 
highBound [1] IMPLICIT FixedLengthInteger, -- Array Upper Bound 
dataType DataTypeSpecification } 
ExpandedFixedLenBitStrTypeSpec ::= SEQUENCE { 
bitStrType DataTypeSpecification -- BYTE, WORD, DWORD, or LWORD 


bitFields [7] IMPLICIT BitFieldDef} 


BitFieldDef ::= SEQUENCE OF { 
bitDef [2] IMPLICIT OCTET STRING} -- Length is always 2 octets. 
—- First octet contains starting 
—-- Bit Position. Trailing octet 
-- contains the number of bits. 
ExpandedStringTypeSpec ::= UINT-- String Length In Octets 
ExpandedString2TypeSpec ::= UINT-- String Length In Octets 
AlternateTypeSpec ::= CHOICE { 
directlyDerivedTypeSpec [0] IMPLICIT TypelID, 
subrangeTypespec [1] IMPLICIT SubrangeTypespec , 
enumeratedTypeSpec [2] IMPLICIT EnumeratedTypeSpec, 
fbTypespec [3] IMPLICIT FBTypeSpec} 
SubrangeTypeSpec ::= SEQUENCE { 
baseType TypelID, —-- NOTE: minValue and maxValue 
minValue FixedLengthInteger, -- must be within the range 
maxValue FixedLengthInteger} -- of baseType values 
EnumeratedTypeSpec ::= SEQUENCE OF AnyString 
BitNameDefintion ::= SEQUENCE { 
bitName AnyString, 
bitNumber USINT} 
FBTypeSpec ::= SET{ 
inputs [0] IMPLICIT FbtElementSpec OPTIONAL, 
outputs [1] IMPLICIT FbtElementTypeSpec OPTIONAL, 


controlInputs [2] IMPLICIT FbtElementTypeSpec OPTIONAL, 
controlOutputs [3] IMPLICIT FbtElementTypeSpec OPTIONAL} 


FbtElementTypeSpec ::= SEQUENCE OF ElementSpec 
ElementSpec ::= SEQUENCE { 

name AnyString, 

typespec ElementTypeSpec } 
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Element TypeSpec 


[0] 
[1] 
[2] 
[3] 
[4] 
[5] 


IMPLICIT 
IMPLICIT 
IMPLICIT 
IMPLICIT 
IMPLICIT 
IMPLICIT 


Appendix C: Data Management 


:= CHOICE { 


TypelID, 
SubrangeTypespec, 
EnumeratedTypeSpec, 
FormalArrayTypeSpec, 
ExpandedStringTypeSpec, 
ExpandedString2TypeSpec} 


Additional elements of “FBTypeSpec” are being considered. 


The following END statement terminates the ASN.1 module opened in section C-4. 


END. 
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C-5.1 


C-5.2 


CIP APPLICATION TRANSFER SYNTAX: 
COMPACT ENCODING 


This section describes the means by which the data types defined in section C-4 Data Type 
Values, are encoded/transferred across CIP. The abstract syntax definition along with a 
particular set of encoding rules results in a transfer syntax. For CIP application user data, a 
single set of encoding rules is defined (Compact Encoding), resulting in the Compact transfer 
syntax. 


Compact Encoding rules start with the encoding rules defined in ASN.1 8825. Compact 
Encoding then applies optimization rules, starting with the outer most Service Data Unit (SDU) 
and progressing to each successive encapsulated SDU. Compact Encoding defines a more 
efficient encoding mechanism by reducing the amount of information (overhead) transferred 
between devices. 


The difference between a Compact encoded value and an ASN.1 encoded value is the removal 
of the fields describing the type and length of the information. In other words, the TAG and 
LENGTH components of an ASN.1-encoded value are not transmitted on CIP. In addition, the 
Compact Encoding rules indicate that octet-ordering rules are the reverse of those seen in 
ASN.1. 


Given the conditions listed in the next section, the following general rules are applied to an 
ASN.1 encoded value to generate a Compact encoded value: 


e Remove the Identifier Octets. Remove the “TAG” octets specified by ASN.1. 
e Remove the Length Octets. Remove the “LENGTH” octets specified by ASN.1. 
e Reverse the byte ordering for multiple content octets. 


Compact Encoding Constraints 


Important: The representation of a variable value using Compact Encoding is only possible 
with the following restrictions: 


e Ina multi-peer communication relationship, the entities involved in the pre-established 
connection have prior knowledge of the variable type, and do not need to transmit the 
type description with the value of the variable. This knowledge is available by accessing 
the description of the variable and the variable type. 

e The variable type is fixed length and has no conditional or optional fields. 

e The encoding of a given variable is represented with a constant number of octets 
derived from the type specification of this variable. 


Encoding Rules/Examples 


This section lists rules specific to the various data types implemented in the CIP system and 
shows examples of the Compact Encoding. 
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C-5.2.1 


C-5.2.2 


C-5.2.3 
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BOOL ENCODING 
The boolean encoding is performed on a single OCTET. 


If the value is: Then: 
FALSE bit 0 of the octet is 0 (00’H) 
TRUE bit 0 of the octet is 1 ?01’H) 


The example illustrated below depicts the encoding of a BOOL whose value is FALSE. 
Table C-5.1. Example Compact Encoding of a BOOL Value 


Octet Number 


BOOL 


SIGNEDINTEGER ENCODING 


This section gives you examples of the Compact Encoding of SINT, INT, DINT, LINT data 
values. A generic illustration of the encoding of SignedInteger values is given below: 


Octet Number 


SINT 


moss fess | [| | 
DINT OLSB 1LSB 2LSB 3LSB (a ie 
LINT OLSB 1LSB 2LSB 3LSB 4LSB 5LSB 6LSB 7LSB 


The following example illustrates the encoding of a variable of type DINT whose value is 
12345678hex.- 


Table C-5.2. Example Compact Encoding of a Signedinteger Value 


Octet Number 1st 2nd 3rd 4th 


DINT E 
UNSIGNEDINTEGER ENCODING 


This section gives you examples of the Compact Encoding of USINT, UINT, UDINT, ULINT, 
and ENGUNIT data values. A generic illustration of the encoding of UnsignedInteger values is 
given below: 


tite! | Fee) eee 
unr fasp | |_| | |_| _| 
UINT jose isp_[ | | |) |__| 
upINT_[orsp_finsp_[aisp_[scsp_[ [|_| 
ENGUNT forss fuse | | | | | _| 


The example below illustrates the encoding of a variable of type UDINT whose value is 
AABBCCDDhex. 
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C-5.2.4 


C-5.2.5 


C-5.2.6 


Table C-5.3. Example Compact Encoding of a UnsignedInteger Value 


Octet Number 4th 
upnt_[pp__|cc [BB [AA 


FIXEDLENGTHREAL ENCODING 


This section gives you examples of the Compact Encoding of REAL and LREAL data values. 
A generic illustration of the encoding of FixedLengthReal values is given below: 


Octet Number 8th 
REAL [OLSB_|1LSB_|2LSB_3LSB_ {| | | 
LREAL TLSB 


The example below illustrates the encoding of a variable (Floatl) whose type is REAL and 
whose value is Floatl: = 10.0. (The assignment of the value is using the IEC 1131-3 notation. 
The ASN.1 value is {?41200000’H} in IEEE format (1.25*23 , exponent is 130(bias 127), 
fraction is 25)). 


Table C-5.4. Example Compact Encoding of a REAL Value 
Octet Contents 3LSB 


REAL 00 41 


The example below illustrates the encoding of a variable (Float2) whose type is LREAL and 


whose value is Float2: =—100.0. ( {?C059000000000000’H} in IEEE format (1.5625*29, 
exponent is 1029 (bias 1023), fraction is .5625)). 


Table C-5.5. Example Compact Encoding of a LREAL Value 
Octet Contents 7LSB 
joo foo foo. —S foo. Ss fos fo f'59 


LREAL C0 
TIME ENCODINGS 


This section gives you examples of the Compact Encoding of TIME, DATE, TIME OF DAY, 
DATE_AND_TIME, FTIME, LTIME, ITIME data values. A generic illustration of the 
encoding of FixedLengthReal values is given below: 


Octet Number 8th 


TIME ete Lee Ga ee ee 
DATE seuss 


TIME_OF_DAY 


DATE _AND_ TIME | OLSB- TSE: 2LSB- | 3LSB- — — 
Time an Time Time i aa 


FTIME 
LTIME ase 


STRING ENCODINGS 


This section gives you examples of the Compact Encoding of STRING, STRING2, STRINGN, 
and SHORT_STRING data values. 


Important: The preferred string type for user supplied string data is STRING2 due to 
international character string requirements. 


Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Appendix C: Data Management 


Release 1.0 


A generic illustration of the encoding of a STRING value is given below: 


Contents Contents 
(charcount) (string contents) 
STRING OLSB 1LSB OLSB 


1 byte character 
A generic illustration of the encoding of a STRING2 value is given below: 
Contents Contents 
(charcount) (string2contents) 
STRING2 OLSB 1LSB OLSB 1LSB 


2 byte character 


A generic illustration of the encoding of a STRINGN value is given below: 
Contents 


Contents Contents 
(charsize) (charcount) (stringNcontents) 


OLSB _....... 1LSB OLSB _....... 1LSB OLSB_........ NLSB 


STRINGN 


N byte character 


A generic illustration of the encoding of aSHORT_STRING value is given below: 


Contents Contents 
(charcount) (short_string) 


SHORT STRING OLSB OLSB 


1 byte character 


The example below illustrates the encoding of a string variable whose contents equal ”Mill”. 
Encoding examples of all string types are presented. Character coding is specified in ISO 
10646. The hexadecimal equivalent is: {’4D696C6C’H} for 8 bit encoding. 


The example below encodes ”Mill” as a STRING type. 
Table C-5.6. Example Compact Encoding of A String Value 
(charcount) (string contents) 
STRING jos fo Soc fc 
The example below encodes ”Mill” as a STRING? type. 


Table C-5.7. Example Compact Encoding of String2 Value 
Contents Contents 
(charcount) (string2 contents) 
STRING2__ [04 f00 4D [0069 Joo Joc oo [6c 00 


2 byte character 
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The example below encodes ”Mill” as a SHORT STRING type. 


Contents 
(short_string contents) 


Contents 
(charcount) 
SHORT STRING 


C-5.2.7 FIXEDLENGTHBITSTRING ENCODING 


This section supplies examples of the Compact Encoding of BYTE, WORD, DWORD, 
LWORD data values. The figure below illustrates the bit placement rules associated with the 
Compact Encoding of a FixedLengthBitString. 


Ussavee 0 BYTE 


The examples below illustrate the encoding of a BYTE, WORD, DWORD, and an LWORD. 


Figure C-5.8. Example Compact Encoding of A BYTE FixedLengthBitString 


Bits In Memory: 


00001111 


Compact Encoded BYTE 
00001111 or OFhex 


Figure C-5.9. Example Compact Encoding of A WORD FixedLengthBitString 
Bits In Memory: 


00001111 11001111 


Compact Encoded WORD 
11001111 00001111 or CFOFhex 


Figure C-5.10. Example Compact Encoding of A DWORD FixedLengthBitString 


Bits In Memory: 
ee hiss con ganscactreassievictacet aseaisaat an neereed 0 
00001111 11001111 10110110 00111110 
Compact Encoded DWORD 


00111110 10110110 11001111 00001111 or3EB6CFOFhex 
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Figure C-5.11. Example Compact Encoding of A LWORD FixedLengthBitString 


Bits In Memory: 


11110000 11001111 10110110 00111110 11110000 00101101 00011110 00001111 


Compact Encoded LWORD 
00001111 00011110 00101101 11110000 00111110 10110110 11001111 11110000 or OF1E2DF03EB6CFFOhex 


ARRAY ENCODING 


The array encoding uses the encoding rules for the CIP Data types for each element and 
concatenates the elements which compose the array. The encoded values of the array elements 
are encoded in the same order as they are declared in the corresponding ASN.1 type or variable 
specification. These elements may be of any CIP Data type. 


Array definitions follow FIP and FieldBus standards, whose committees are currently planning 
to specify the bounding limits for each dimension of an array. The ASN.1-style definition of a 
single—dimensional array in a CIP network is: 


ARRAY ::= SEQUENCE OF { array_dimension_low_bound, 
array_dimension_high_bound, CIPData } 


Assume the following array definition:: 


ARRAY1 ::= SEQUENCE OF {array dimension low bound := 0, 
array dimension high bound := 1, UINT} 


Plugging the UINT values {1,2} into this array definition yields the following encoding: 
Table C-5.12. Example Compact Encoding of a Single Dimensional ARRAY 


Octet Number 4th 


ARRAY 


The ASN. 1-style definition of a two—dimensional array in a CIP network is: 


ARRAY ::= SEQUENCE OF { array dimension low bound, 
array dimension high bound, 

SEQUENCE OF { array dimension low bound, 
array dimension high bound, 
CIPData } } 


The ASN. 1-style definition of a three—dimensional array in a CIP network is: 


ARRAY ::= SEQUENCE OF { array dimension low bound, 

array dimension high bound, 

SEQUENCE OF { array dimension _low_bound, 

array dimension high bound, 

SEQUENCE OF { array dimension _low_bound, 
array dimension high bound, 
CIPData } } } 
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C-5.2.9 


Since CIPData may comprise either ElementaryData or DerivedData, a new type or variable 
specification may be required before transmitting the values for the ARRAY. 


A multi—dimensional array is seen on the wire as a single—dimensional array. The order of the 
array elements is maintained via the packing/unpacking sequence followed by the end nodes. 
The sequence followed is to access the Nth dimension of the array for all values of the other 
dimensions. 


This is achieved by first accessing the array with all dimensions set to their initial index values. 
After this the Nth dimension is incremented through all of its index values. When the end of the 
index range for the Nth dimension is reached, the (N-1)th dimension is incremented, and the 
Nth dimension is set to its initial index value. This process is repeated until all of the array’s 
dimensions have reached the ends of their index ranges, and results in the array being packed 
into the message buffer as a single—dimensional array. The same procedure is followed to 
unpack the single—dimensional array into a multi-dimensional array. 


The two-dimensional array shown results in the data stream below when it is packed into a 
single—dimensional array following the compact encoding rules: 


ARRAY1 [0..1 , 0..2] of UINT := { { 1, 2, 3 },{ 4, 5, 6 } } 


Table C-5.13. Example Compact Encoding of a Multi-Dimensional ARRAY 


= [oe [on [oe [oon [om [os [ov [i 
rofwlefwfe two lwlslwlwla 
STRUCTURE ENCODING 


The structure encoding uses the encoding rules for the CIPData types for each element and 
concatenates the elements which compose the structure. 


Octet Number 


ARRAY 


The encoded values of the structure elements are encoded in the same order as they are 
declared in the corresponding ASN.1 type or variable specification. These elements may be of 
any CIPData type. 


STRUCT ::= SEQUENCE OF CIPData —- May be different types 


Since CIPData may be comprised of either ElementaryData or DerivedData, a new type or 
variable specification may be required before transmitting the values for the STRUCT. 


Assume the following structure definition: 
newStruct ::= SEQUENCE { BOOL,UINT,DINT} 


Plugging the values {TRUE,’1234’H,’56789ABC’H} into the structure results in the following 
encoding: 


Table C-5.14. Example Compact Encoding of a STRUCTURE 


onaenie| ow] om oa] wo] Sm | on] om 
msn [or Lo fe [oc] om | ws 
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C-5.2.10 EXAMPLES OF HOW MORE COMPLEX DATA FORMATS ARE ENCODED 


The examples below show how more complex data formats are packed. Example | shows the 
packing of an array of structures. Example 2 shows how a structure with an array element is 
packed. 


Example 1: Encoding an Array Of Structures: 


STRUCT1 ::= SEQUENCE OF { 
UINT elel; 
USINT ele2; 
USINT ele3; 
USINT ele4; 
UINT eled5 


2, 3, 4, 5 }, { 6, 7, 8, 9, 10 }, 


Example 2: Encoding a Structure with an Array Element 


STRUCT2 ::= SEQUENCE OF { 
UINT elel; 
ARRAY [ 0..2 ] of USINT array2; 
UINT ele5; 

} 

STRUGT2: 2s=- {0 dy. Ao 29. Sy A hy By} 


results in the following data stream: 


[01] [00] [02] [03] [04] [05] [00] 
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Objects may choose to implement a mechanism for reporting Data Type of a particular 
Attribute or transmitting type information along with the actual data. This section defines the 
means by which Data Typing information is conveyed. 


The specification of CIP Data Type information utilizes the ASN.1 methodology specified in 
ISO 8824:1987(E) and ISO 8825:1987(E) with CIP defined optimizations to encode the 
DataTypeSpecification production defined in section C-4.2. The CIP defined optimizations 


are listed below: 


e The Length Octet of a NULL type is not encoded. For example; the encoding of 
‘abc [PRIVATE 1] IMPLICIT NULL’ would be: Clhex (a tag with no length octet). 


The sections that follow detail: 


e Elementary Data Type Reporting 
e Constructed Data Type Reporting 


Elementary Data Type Reporting 


Elementary data types are identified using the identification codes defined in the table below. 
These codes illustrate the encoding of the primitive members of the DataTypeSpecification 
production. Remember that CIP specifies that ASN.1 NULL types do not report the Length 


Octet of zero (0). 


Table C-6.1. Identification Codes and Descriptions of Elementary Data Types 


Data Type Description 


Logical Boolean with values TRUE and FALSE 


character string (1 byte per character) 


Data Type 
Name Code (in hex) 

SINT Signed 8-bit integer value 
INT Signed 16-bit integer value 
DINT Signed 32-bit integer value 
LINT Signed 64-bit integer value 
USINT Unsigned 8—bit integer value 
UINT Unsigned 16-bit integer value 
UDINT Unsigned 32-bit integer value 
ULINT Unsigned 64-bit integer value 
REAL 32-bit floating point value 
LREAL 64-bit floating point value 
STIME Synchronous time information 
DATE Date information 
TIME_OF DAY Time of day 
DATE AND. TIME Date and time of day 
STRING po 
BYTE bit string - 8-bits 
WORD bit string - 16-bits 
DWORD bit string - 32-bits 
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Data Type Data Type Description 
Name Code (in hex) 
LWORD bit string - 64-bits 
STRING2 character string (2 bytes per character) 
FTIME [D6 Duration (high resolution) 
LTIME Duration (long) 
ITIME [Ds Duration (short) 
STRINGN [Do character string (N bytes per character) 
SHORT_STRING character sting (1 byte per character, 1 byte length indicator) 
TIME [DB Duration (milliseconds) 
EPATH CIP path segments 
ENGUNIT [Db Engineering Units 


Constructed Data Type Reporting 


This section details the means by which the structure and array information presented within 
the DataTypeSpecification production is represented. 


STRUCTURE TYPE DEFINITION 
CIP defines two different methods for reporting Structure Type Definitions: 


e Formal Encoding (FormalStrucTypeSpec) 
e Abbreviated Encoding (AbbreviatedStrucTypeSpec) 


Formal encoding is used to provide a detailed report of the complete structure definition, 
including the complete definition of all component data types. Abbreviated encoding is used to 
specify a shorter form of the structure definition. This shorter form does not include the data 
types associated with the structure’s components. 


Formal Encoding for Structure Type Information 
The two examples below illustrate formal encoding for structure type specifications. This is 
actually an example of the encoding of the FormalStrucTypeSpec production defined in 


section C-4.2, Data Specification/Dictionaries. 


Example 1: 
Table C-6.2 shows the encoding of the following structure definition 


STRUCT ::= SEQUENCE OF { BOOL, UINT, DINT } 


Table C-6.2. Example 1 of Formal Encoding of a Structure Type Specification 


followed by a Length Octet of zero (0). 
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Struc Type Length Component Component Component Types 
Type Types Types 
BOOL UINT DINT 
A2 03 Cl C7 C4 
Note that the IMPLICIT NULL types from the DataTypeSpecification production are not 
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Example 2: 

Table C-6.3 shows the encoding of the following structure definition 
STRUCT_MAIN ::= SEQUENCE OF { UINT, STRUCT_SUB, INT } 
with subelement STRUCT_SUB defined as: 

STRUCT_SUB ::= SEQUENCE OF { UINT, SINT, INT } 


Table C-6.3. Example 2 of Formal Encoding of a Structure Type Specification 


Component 
Type Struct Type Nested Component 
Struct Length UINT Type Length UINT SINT INT INT 
A2 07 C7 A2 03 C7 C2 C3 C3 


Abbreviated Encoding for Structure Type Information 


The example below illustrates the abbreviated encoding for structure type specifications. This 
is actually an example of the encoding of the AbbreviatedStrucTypeSpec production defined 
in section C-4.2, Data Specification/Dictionaries. 


The UINT defined within the AbbreviatedStrucTypeSpec production is initialized with a 16 bit 
Cyclic Redundancy Check (CRC) value. This can be used by application logic to determine 
whether or not the format of the structure has changed. The byte stream used to produce the 
CRC is the actual formally encoded (FormalStrucTypeSpec) structure type specification. See 
Section J-7, CRC Generation Algorithms. 


Example: 


Table C-6.4 shows the abbreviated encoding of the structure definition presented in the 
previous section: 


Table C-6.4. Example of Abbreviated Encoding of a Structure Type Specification 


Struc Type Length UINT Containing CRC 
AO 02 C7 26 


Note that the algorithms presented in section used to generate the CRC value of 26C7hex from 
the Formally Encoded type specification: [A2][07][C7][A2][03][C7][C2][C3][C3]. 


C-6.2.2 Array Type Definition 


CIP defines two different methods for reporting Array Type Definitions: 


e Formal Encoding (FormalArrayTypeSpec) 
e Abbreviated Encoding (AbbreviatedArrayTypeSpec) 
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Formal encoding is used to provide a detailed report of the complete array definition, including 
the data content and the array’s dimensions. Abbreviated encoding is used to specify a shorter 
form of the array definition. This shorter form does not include information specifying the 
array’s dimensions. 


Formal Encoding for Array Type Information 
The two examples below illustrate formal encoding for structure type specifications. This is 
actually an example of the encoding of the FormalArrayTypeSpec production defined in 
section C-4.2, Data Specification/Dictionaries. 
Example 1: 
Table C-6.5 shows the formal encoding of the following array definition 
ARRAY 1 ::= SEQUENCE OF { array_dimension low_bound := 0, 
array dimension high bound := 9, 


UINT } 


Table C-6.5. Example 1 of Formal Encoding of An Array Type Specification 


Lower Lower Upper Upper 
Type Bound Bound Lower Bound Bound Upper 
Array Length Tag Length Bound Tag Length Bound UINT 
A3 07 C7 01 00 81 01 09 C7 


Note that the IMPLICIT NULL types from the DataTypeSpecification production are not 
followed by a Length Octet of zero (0). 


Example 2: 

Table C-6.6 shows the encoding of the following array definition 

ARRAY1 ::= SEQUENCE OF { array_dimension low bound := 0, 
array_dimension_high bound := 19, 


SEQUENCE OF { array_dimension_low_bound := 0, 
array_dimension_high bound := 255, STRUCT_ELE} 


} 


in which STRUCT_ELE is defined as: 


STRUCT_ELE ::= SEQUENCE OF { UINT, SINT, INT } 
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Table C-6.6. Example 2 of Formal Encoding of an Array Type Specification 


Formal Encoding: 


[A3] [13] [80] [01] [00] [81] [01] [13] [A3] [OB] [80] [01] [00] [81] [01] [FF] [A2] [03] [C7] [C2] [C3] 


Lower Lower Upper Upper 
Array Type Bound Bound Lower Bound Bound Upper 
Type Length Tag Length Bound Tag Length Bound 
A3 13 80 01 00 81 01 13 2 
Array Contents 
Lower Lower Upper Upper 
Array Type Bound Bound Lower Bound Bound Upper 
Type Length Tag Length Bound Tag Length Bound 


Nested Array Contents 
Struct Type 
Type Length UINT SINT INT 


A2 03 C7 C2 C3 


Note that the IMPLICIT NULL types from the DataTypeSpecification production are 
not followed by a Length Octet of zero (0). 


Abbreviated Tag Encoding for Array Type Information 
The abbreviated encoding of an Array type DOES NOT include the information specifying the 
Array’s dimensions. This is actually an example of the encoding of the 
Abbreviated ArrayTypeSpec production defined in section C-4.2, Data 
Specification/Dictionaries. 
Example 1: 
Table C-6.7 shows the abbreviated encoding of the following array definition: 
ARRAY? ::= SEQUENCE OF { array_dimension low_bound := 0, 
array dimension high bound := 9, 


UINT } 


Table C-6.7. Example 1 of Abbreviated Encoding of an Array Type Specification 


Array 
Type Type Length UINT 
Al 01 C7 


Note that the IMPLICIT NULL types from the DataTypeSpecification production are not 
followed by a Length Octet of zero (0). 
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Example 2: 

Table C-6.8 shows the abbreviated encoding of the following array definition: 

ARRAY ::= SEQUENCE OF { array dimension low bound := 0, 
array_dimension_high bound := 19, 


SEQUENCE OF { array dimension low bound := 0, 
array_dimension_high bound := 899, STRUCT_ELE } 


} 
in which STRUCT_ELE is defined as: 
STRUCT_ELE ::= SEQUENCE OF { UINT, SINT, INT } 


Table C-6.8. Example 2 of Abbreviated Encoding of an Array Type Specification 


Array Contents 


Nested Component 


Array Type Array Type Struct Type UINT Containing 
Type Length Type Length Type Length CRC 
Al 06 Al 04 AO 02 59 51 
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The C routine below generates a CRC via the polynomial driven method. 


[RR KKK KKK KKK KKK KKK KK KK KK KK KK OK KKK KK KK OK KK KK KKK KK 


Function Name: 
Description: 


calcP 


olyCrc() 


calculates a Cyclic Redundancy Checksum CRC) 


polynomial driven method. 


Inputs: 


via the 


start_addr - the address of the first byte which is 


involved in the cre calculation 


size - the number of consecutive bytes that are 


involved in the cre calculation. 
a 16 bit value containing the calculated CRC 


Outputs: 


Size of 0 is invalid. 


KOR KK KK KK OK KK OK OK KK OK OK OK KK KK / 


unsigned16BitInteger calcPolyCrec(start_addr, 


unsigned8BitInteger *start_addr; 


unsigned32BitInteger 
{ 
unsigned16BitInteger 
unsigned&BitInteger 
unsigned&8BitInteger 
unsigned32BitInteger 


ere 0; 
while 


{ 


(size) 


carry 
cre > 


(unsigned8&BitInteger) 


size; 


erc; 
carry; 
b; 
cnt; 


8) 


cre & 1; 


>= 1; 


if (carry) 


cre 


entt++ 
} 
size--; 
} 
return (crc); 


} 
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size) 


*start_addr++; 
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The C routine below generates a CRC via the table driven method. 


unsigned1l6BitInteger poly_table[] = {0x0000, OxCOC1, 
OxC181, 0x0140, OxC301, 0x03C0, 0x0280, 
OxC241, OxC601, 0x06CO, 0x0780, OxC741, 
0x0500, QxC5SCl, OxC481, 0x0440, OxCCOl1, 
Ox0CCO, 0x0D80, OxCD41, Ox0FOO, OxCFC1, 
OxCE81, Ox0E40O, OxO0AO0O, OxCAC1, OxCB81, 
0x0B40, Oxc901, 0x09C0, 0x0880, OxC841, 
OxD801, 0x18CO, 0x1980, OxD941, 0x1BO00, 
OxDBC1, OxDA81, 0x1A40, Ox1E00, OxDEC1, 
OxDF81, Ox1F40, OxDDO1, 0x1DCO, 0x1C80, 
OxDC41, 0x1400, OxD4Cl1, OxD581, 0x1540, 
OxD701, 0x17CO, 0x1680, OxD641, OxD201, 
Ox12CO, 0x1380, OxD341, 0x1100, OxD1Cl1, 
OxD081, 0x1040, OxFOO01, 0x30C0, 0x3180, 
OxF141, 0x3300, OxF3Cl1, OxF281, 0x3240, 
0x3600, OxF6Cl1, OxF781, 0x3740, OxF501, 
0x35C0, 0x3480, OxF441, 0x3C00, OxFCC1, 
OxFD81, 0x3D40, OxFFO1, Ox3FCO, 0x3E80, 
OxFE41, OxFAO1, 0x3ACO, 0x3B80, OxFB41, 
0x3900, OxF9C1, OxF881, 0x3840, 0x2800, 
OxE8Cl1, OxE981, 0x2940, OxEBO1, Ox2BCO, 
Ox2A80, OxEA41, OxEEO1, Ox2ECO, Ox2F80, 
OxEF41, O0x2D00, OxEDC1, OxEC81, 0x2C40, 
OxE401, 0x24CO, 0x2580, OxE541, 0x2700, 
OxE7C1, OxE681, 0x2640, 0x2200, OxE2Cl1, 
OxE381, 0x2340, OxE101, 0x21C0, 0x2080, 
OxEO41, OxA001, 0x60CO, 0x6180, OxA141, 
0x6300, OxA3Cl1, OxA281, 0x6240, 0x6600, 
OxA6Cl1, OxA781, 0x6740, OxA501, 0x65C0, 
0x6480, OxA441, 0x6CO00, OxACC1, OxAD81, 
0x6D40, OxAFO1, Ox6FCO, Ox6E80, OxAE41, 
OxAAO1, Ox6ACO, 0x6B80, OxAB41, 0x6900, 
OxA9C1, OxA881, 0x6840, 0x7800, OxB8Cl1, 
OxB981, 0x7940, OxBBO1, O0x7BCO, Ox7A80, 
OxBA41, OxBEO1, Ox7ECO, Ox7F80, OxBF41, 
Ox7DO0O, OxBDC1, OxBC81, 0x7C40, OxB401, 
0x74CO, 0x7580, OxB541, 0x7700, OxB7Cl1, 
OxB681, 0x7640, 0x7200, OxB2Cl1, 0OxB381, 
0x7340, 0OxB101, 0x71C0, 0x7080, OxB041, 
0x5000, Ox90C1, 0x9181, 0x5140, 0x9301, 
0x53C0, 0x5280, 0Ox9241, 0x9601, 0x56C0, 
0x5780, Ox9741, 0x5500, Ox95Cl1, 0x9481, 
0x5440, Ox9C01, O0x5CCO, Ox5D80, Ox9D41, 
Ox5F00, Ox9FC1, Ox9E81, 0Ox5E40, 0x5A00, 
Ox9AC1, Ox9B81, 0Ox5B40, 0x9901, 0x59C0, 
0x5880, 0x9841, Ox8801, 0x48C0, 0x4980, 
0x8941, 0x4BO00, Ox8BCl1, Ox8A81, Ox4A40, 
0x4E00, Ox8EC1, Ox8F81, Ox4F40, Ox8D01, 
Ox4DCO, 0x4C80, Ox8C41, 0x4400, Ox84Cl1, 
0x8581, 0x4540, 0x8701, 0x47CO, 0x4680, 
0x8641, 0x8201, 0x42CO, 0x4380, 0x8341, 
0x4100, O0x81Cl1, 0x8081, 0x4040}; 
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calcTableCrc() 
Description: Calculates a 16 bit crc value based on the input 
parameters via the table driven method 
Inputs: start_addr - pointer to the first byte of memory 
involved in the calculation of the CRC 

size - the number of bytes to include in the CRC 
generation 
Outputs: a 16 bit CRC 


KKK KK OK KK KK KK KK OK OK KK OK OK OK KK OK / 


unsigned16BitInteger calcTableCrc(start_addr, size) 
unsigned&BitInteger *start_addr; 
unsigned32BitInteger size; 

{ 

unsignedl6BitInteger crc; 

unsigned16BitInteger data; 


cre = 0; 
while (size) 
{ 
data = (unsigned16BitInteger) * start_addr++; 
cre = ((cre >> 8) * poly_table[(cre * data) & 255]); 
size--; 


} 


return (crc); 
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D-1 


D-1.1 


D-1.2 


Introduction 


In the physical sciences, quantities are measured by comparing them to a quantity whose 
magnitude is defined to be unity. Such a quantity is called a unit. For example, a commonly 
used unit for mass is the kilogram. 


Within the CIP specification, units are often used to describe a device’s interface to the 
physical world. For example, a photoelectric switch might use units of length to describe its 
min/max detect distances, and a position controller might use units of velocity and acceleration 
to describe its movements. 


This appendix defines a system of units for use in the CIP specification, including names, 
symbols, and a mechanism for reporting units. This system of units uses the commonly 
recognized name engineering units. 


Reporting Engineering Units (ENGUNIT Codes) 


An attribute of data type ENGUNIT is used to specify the engineering units for one or more 
other attributes. 


By providing a ENGUNIT attribute, an object can manage different engineering units. For 
example, an analog sensor object with a ENGUNIT attribute could potentially measure 
temperature, flow, pressure, and so on. 


If the engineering unit used by an object does not vary, the unit can be specified in the object’s 
specification, and a ENGUNIT attribute is not needed. In such cases, names and symbols of 
units listed in the object’s specification should remain consistent with this appendix. 


The ENGUNIT code is used to represent engineering units only, and does not imply a specific 
data type, range, or scaling. For example, if the engineering units of a UINT (16-bit unsigned 
integer) attribute is defined by another ENGUNIT attribute which indicates milliamps, this 
does not imply a range of 0-65535 mA. The encoding ofa given unit by an object is defined 
entirely by that object’s specification. 


The ENGUNIT data type is encoded as a UINT (16-bit unsigned integer). The most significant 


byte of this UINT selects a group of similar units, and the least significant byte selects a 
specific unit within that group. 


Groups of Engineering Units 


The following groups of engineering units are listed in the tables of section D-2: 


Value of MSB Engineering Units Group 


08 hex thru OF hex Vendor specific enumerations 
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Value of MSB Engineering Units Group 


Acceleration 

Amount of Substance 
Capacitance 
Charge (Electric Charge) 
Conductance (Electric Conductance) 
Current (Electric Current) 
Energy (Heat, Work) 
Frequency (includes RPM) 
Inductance 
Length (Distance, Displacement) 
Light (Luminous Intensity) 
Magnetic Flux 
Power (Wattage) 
Resistance (Electric Resistance) 
Torque (Moment of Force) 
Velocity (Speed) 

2E hex Volume 


D-1.3 Naming Conventions 


In the tables of section D-2, each unit lists: 
e Value: Value used to represent the unit ina ENGUNIT attribute 
e Name: Commonly used name for the unit (often used for text or display) 
e Symbol: Commonly used symbol for the unit (often used for expressions) 


e Base Units: Expression in terms of other base units (such as metric conversions) 
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Many of the names, symbols, and expressions are taken from the International System of Units 
(SI. * 


In addition, the following conventions are taken from SI specifications: 


e The following SI prefixes are used for names and symbols in order to form decimal 
multiples and submultiples of units as appropriate: 


0 M 
10! deka (or deca) da 


e Unit symbols and unit names are not used together. For example, millivolt and mV are 
valid, but mvolt and milliV are not valid. 


e A name (symbol) prefix is inseparable from its unit name (symbol). For example, milli 
amp and milli-amp are not valid names. 


e Acentered dot (‘e’) is used to indicate multiplication, and a solidus (‘/’) is used to 
indicate division. 


e Each unit definition is listed in its singular form. For example, velocity is listed as 
meter per second, not meters per second. Plural forms are more commonly used in 
values for a given unit (such as 8 meters per second). 


e Capitalization follows SI conventions. 


Also, in order to offset footnote markers from other superscripts, each footnote marker is 
preceded by the # symbol. 


' The International System of Units (SI), NIST Special Publication 330, United States Department of Commerce, Tech-nology Administration, 
National Institute of Standards and Technology. See also: Guide for the Use of the Inter-national System of Units (SI), NIST Special Publication 
811. These documents may be available for access on ww.nist.gov. 
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D-2 TABLES 


D-2.1 Profile Specific Engineering Unit Enumerations 


Smal 


0000 hex through 07FF hex Reserved to prevent overlap with the SEMI Standard 


D-2.2 Vendor Specific Engineering Unit Enumerations 


Saal 


0800 hex through OFFF h 
a = This range of values is reserved for Engineering Units specific to a particular vendor’s 


needs. Any device that utilizes values within this range must enumerate (or otherwise 
identify) the exact meaning of each value that can be represented. These values are 
reserved for previously un-enumerated Engineering Units. Engineering units that are 
already represented by enumer-ations in the following sections are not allowed to be 
assigned in this vendor specific range. 


D-2.3 General 


a 
a 
[to02ex | _parpernilion eoneenaion) | mf —SSSSS—*™ 
FT 
a 
a 
FO 
a 
[T008-10FF x_n orfowresendaeaion | sd SS 


D-2.4 Time (includes Date) 


1100 | -1100hex second *” 


a 


> The second is an SI base unit, defined as the duration of 9192631770 periods of the radiation corresponding to the transition between the two 
hyperfine levels of the ground state of the cesium-133 atom. 


> When the millisecond unit is encoded with INT data type, it is equivalent to the ITIME data type defined in Appendix C. When the millisecond unit 
is encoded with DINT data type, it is equivalent to the TIME data type defined in Appendix C. 


“ When the microsecond unit is encoded with DINT data type, it is equivalent to the FTIME data type defined in Appendix C. When the 
microsecond unit is encoded with LINT data type, it is equivalent to the LTIME data type defined in Appendix C. 
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Symbol 
1107 hex DATE * 


1109 hex DATE_AND. TIME * | pr 


i 
110A-11FF hex reserved for future standardization ee ee 


D-2.5 Temperature 


Value Name Symbol Base Units 


1200 hex degree Celcius ” K - 273.15 
1201 hex degree Fahrenheit 


Ko) 45967 
a. 
P. 
tm 


1204-12FF hex reserved for future standardization Po 


D-2.6 Pressure 


1300 hex pound-force per square inch (psi) 


p 6.894757 © 10° « Pa 


Symbol 


1 
Parkes | ilimecrormeny aro | mi | | 
fp ashex | __centineterorwater@ 2G | moor | 
Posies [inch of water tase) «miko | id 
a1 
10° 


b 
Ss 
as 


Re - — <9 
D-2.7 Flow 
| Symbol 


Simba 
1400 hex standard cubic centimeter per minute SCCM Po 
1401 hex standard liter per minute SLM | 


> The DATE unit and its symbol refer to the CIP DATE data type defined in Appendix C. 


° The TIME _OF DAY unit and its symbol refer to the CIP TIME OF DAY data type defined in Appendix C. 
7 The DATE_AND_TIME unit and its symbol refer to the CIP DATE_AND_TIME data type defined in Appendix C. 


* Although the correct SI name is degree Celcius, this unit is often named degree centigrade. 


9 


4 


he kelvin is an SI base unit, defined as the fraction 1/273.16 of the thermodynamic temperature of the triple point of water. 
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D-2.8 Acceleration 


Value Name Symbol Base Units 


Te 
a 


D-2.9 Amount of Substance 


D-2.10 Angle 


'° The mole is an SI base unit, defined as the amount of substance of a system which contains as many elementary entities as there are atoms in 0.012 
kilogram of carbon 12. When the mole is used, the elementary entities must be specified and may be atoms, molecules, ions, electrons, other 
particles, or specified groups of such particles. 


"' The radian is defined as the plane angle between two radii of a circle that cuts off on the circumference an arc equal in length to the radius. 


" The steradian is defined as the solid angle that, having its vertex in the center of a sphere, cuts off an area of the surface of the sphere equal to that 
of a square with sides of length equal to the radius of the sphere. 
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a 
1705 hex arc second (second) (1/60)‘ 
1706-17FF hex reserved for future standardization hn | 


D-2.11 Area 


a 
a 


1 
OO 
[RFT hee | _ ewer fawrestndaeaion sd SS 


D-2.12 Capacitance 


1903 hex nanofarad 
[worssrrhe | esenedorfuuresandadzaton [Sid SSSCSCS~S 


D-2.13 Charge (Electric Charge) 


1A03 hex nanocoulomb 
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1A07 hex exposure (x and y rays) kg'eAes 
1A08-1AFF hex reserved for future standardization Po 


D-2.14 Conductance (Electric Conductance) 


D-2.15 Current (Electric Current) 


Value Name Symbol Base Units 
1C00 hex ampere *!? 


D-2.16 Energy (Heat, Work) 


British thermal unit Btu 


'3 The ampere is an SI base unit, defined as the constant current which, if maintained in two straight parallel conductors of infinite length, of 
negligible circular cross section, and placed 1 meter apart in vacuum, would produce between these conductors a force equal to 2 X 107 newton 
per meter of length. 
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1DOB hex British thermal unit per degree Fahrenheit 1.899101 ¢ 10° e WK 


DI-IDRF ex | eeewel orfuwresaniinizaion [PS 


D-2.17. Force 


1E01 hex surface tension N/m 
[TRS TEFFha [ened orhamresendamation Sid SS 


D-2.18 Frequency (includes RPM) a 


3 


1F0S5 hex counts per millisecond 10° es 


a 
A 


‘4 The electronvolt is a unit which is accepted for use with SI units. However, the accepted value for leV has been experimentally obtained and the 
base units shown does not represent an exact value. 


'S For the purposes of this appendix, Frequency is defined as rate of occurrence (for a specified event). 


'6 Usage of the symbols Bd and hd is also acceptable. 
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Sal 
1FOE hex revolution per second (rps) rps "7 aan) 
1FOF hex revolution per minute (rpm) rpm *!8 1.047198 ¢ 10°! e rad/s 


1F11 hex revolution per day r/d Po 
1F12-1FFF hex reserved for future standardization a ee 


D-2.19 Inductance 


[aoraorr ier [ ened erfawesandadaves [id 


D-2.20 Inertia 


Ee Ce, Oe 
[aoe ie [evel orfumresendadraton id SY 


D-2.21 Length (Distance, Displacement) 


a 


'7 Usage of the symbols RPS and r/s is also acceptable. 
'S Usage of the symbols RPM and r/min is also acceptable. 


'° The meter is an SI base unit, defined as the length of the path traveled by light in vacuum during a time interval of 1/299792458 second. 


D-12 Open DeviceNet Vendor Assoc. & ControlNet International Release 1.0 


Volume 1: CIP Common Specification Appendix D: Engineering Units 


a 


220E hex parsec 3.085678 ¢ 10'°em 


220F hex point (computer) | (1/72) in 
2210 hex point (printer’s) i) cal 3.514598 e 1076 
2211-22FF hex reserved for future standardization ——j 


D-2.22 Light (Luminous Intensity) 


a 
0 
a 
mosh | esenedieriuesendadaaion [sid SSC—S 


D-2.23, Magnetic Flux 


a 
[Suze en [ised for fowesentaaion [iP 


D-2.24 Mass 


Saal 


[aera [sen awe sendin 


°° When using the symbol for nautical mile (nm), care should be taken to avoid confusion with the symbol for nanometer. 


?| The candela is an SI base unit, defined as the luminous intensity, in a given direction, of a source that emits monchro-matic radiation of 
frequency 540 X 10’ hertz and that has a radiant intensity in that direction of (1/683) watt per steradian. 


» The kilogram is an SI base unit, defined as the mass of the international prototype of the kilogram. 
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D-2.25 Power (Wattage) 


2600 x Wn 


260E hex thermal conductivity Wi(m eK) mekges*eK" 


260F-26FF hex reserved for future standardization i. -aho- 7. — 


D-2.26 Radiology 


2700 hex activity of a radionuclide (becquerel) a ae 
2701 hex absorbed dose (gray) Gy | mes? 


2702 hex dose equivalent (sievert) Sv 


2706 hex rad 


2708-27FF hex reserved for future standardization 


R 


rad #23 


D-2.27 Resistance (Electric Resistance) 


36 A2 


2801 hex milliohm mQ 


sl 
mes 
mes 
mes’ 
3.7 


2 
2 
3 


010% Bq 
2.58 © 104 Chkg 
fe 


Q 10° e Q 


°3 When there is risk of confusion with the symbol for the radian, rd may be used as the symbol for rad. 
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Value 
2806 hex 


Name 


median 


2809 hex ohm centimeter Qecm 10°eQem 


280A-28FF hex reserved for future standardization a | P| 


D-2.28 Sound 


Name 
Intensity (Wem”) Po 
Sound Intensity Level 
Sound Pressure Level 


2807 hex 
2808 hex 


Voltage Level re 1mW across 600Q 
Voltage Level re 1 V 

Voltage Level re 1 nV Po 
reserved for future standardization Po 


D-2.29 Torque (Moment of Force) 


oa i eee | 


ounce-force inch (ounce-inch) 
torque per ampere (mili) 10° e ((N m)/A) Pol 
reserved for future standardization a 


4 Sound Intensity Level is 10eloge( I/I, ), where I, = 10°'? W/m? in air and 6.66 10°? W/m? in water. 
> Sound Pressure Level is 20eloge( P/P, ), where P, = 20 uPa in air and 1 Pa in water. 
6 Voltage Level re ImW across 600Qis 20eloge( V/.775 ), when the reference impedance is 600Q. 


"7 Voltage Level re 1 V is 20eloge( V/1 ), where the impedance ratio is generally ignored. 
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D-2.30 Velocity (Speed) *”* 


0s er [ea prio ——[ | tye 
[anos [tpn am 
a 
a 

a is 


D-2.31 Viscosity 


a 
2C01 hex poise 10'e Paes 
a a a a 


D-2.32 Voltage 


Toke 


2D05 hex femtovolt 


°8 For the purposes of this appendix, Velocity uses the traditional definition of distance over time, and thus units for baud rate and rpm are listed in 
the Frequency group. 
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D-2.33 Volume 


a 
a 


a A 
[SEOE-2ERF ex [weve fore sandadavon | 


D-2.34 Density 


a 


[arom masdeniy Ym PS 
-—2r0vhe [coins mt |S 
[2F0Atex [counterion | tat [| —SSSSS—S 
[SFOB2FFF he | _eewel orfawrestndadaton sd SS 


°° The letter L was adopted by the General Conference on Weights and Measures (CGPM) in order to avoid the risk of confusion between the letter | 
and the numeral 1. Both the letter 1 and the letter L are internationally accepted symbols for the liter. According to Interpretation of the SI for 
the United States and Metric Conversion Policy for Federal Agencies (National Institute for Standards and Technology Pub 814), to avoid this 
risk, the symbol to be used in the United States is the letter L. 
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